Proposal Summary
This proposal suggests that the [DIP-31] Development Roadmap for 2025-mid-2026 by SSV Labs (hereinafter: “DIP-31”) section regarding SSV 2.0 be amended as a consequence of the [DIP-31] research completed under the aforesaid section.
Motivation
DIP-31 SSV 2.0 section provided expansive descriptions what the capabilities of the ssv.network could be if various based apps were to be created and run on the ssv.network: …”by leveraging Ethereum’s validator set, Based Applications introduce a new class of decentralized applications that derive security from existing Ethereum validators, rather than relying on self-bootstrapping mechanisms or solely on capital from restaking protocols.”
DIP-31 stated that: “… SSV 2.0 establishes the foundation for Based Applications by creating a structured protocol that enables validators to secure multiple applications, ensuring robust security, decentralization, and scalability”.
With this in mind, SSV.labs has set out, researched, and developed a bApps testnet, introduced it to industry participants, and has seen firsthand the traction this direction yielded. It quickly became apparent that the search for many potential bApps was a highly dispersed approach, which, while garnering interest, was trumped by the potential of one bApp that, like DVT, fills a crucial gap in Ethereum. By using the bApp framework developed for SSV2.0 it’s possible to create a bApp that is a synchronous composability protocol with a shared publisher (hereinafter: “Compose”).
Technical discussions were held between the DAO core contributors, the SSV Foundation and SSV.labs regarding this new direction, and as such, is being presented to the wider DAO for comment on this proposal.
Marketing discussions were held between SSV.labs and the SSV Foundation according to the [DIP-35] Amendment of the [DIP-28] budget regarding Compose. The SSV Foundation within its discretion approved the Compose brand, associated website, and x account.
Therefore, there is a need for the ssv.network DAO to provide its feedback on the Technical discussion regarding Compose, and ultimately vote to approve the particularization of the initial bApps vision of DIP-31.
Proposal Particulars
- Proposal Summary
- Motivation
- DIP-31 Amendment
- Future Iterations
DIP-31 Amendment
If this proposal were to pass the everything mentioned under the section SSV 2.0 of DIP-31 will be replaced with the following:
SSV 2.0 represents the next evolution of the SSV protocol, expanding its capabilities beyond Distributed Validator Technology (DVT). It provides an infrastructure for a network of rollups with the purpose of solving a main problem in the L2 landscape: fragmentation. Prior solutions either rely on asynchronous message passing, lacking atomicity and suffering with high latencies, or on shared sequencing, which provides atomicity but requires vertical scaling and removes the rollup sovereignty over the sequencer role (i.e. over transaction inclusion and ordering, and fee markets). The SSV Rollup Stack, on the other hand, preserves rollups sovereignty while achieving horizontal scaling by enabling synchronous and atomic cross-chain transactions through a decentralized protocol between the rollups’ sequencers and a new entity: the shared publisher.
1. SSV Node
1.1. Sequencer Node - The Company will develop a sequencer client for rollups, responsible for including and ordering transactions, and producing the rollup block. The sequencer node’s development encompasses:
1.1.1. Synchronous Composability Protocol (SCP) Module: Responsible for the correct participation in the decision making process of including or not a cross-chain transaction. With this module, the sequencer will be able to exchange mailbox messages with other sequencers and vote on the Two-Phase Commit (2PC) protocol managed by the Shared Publisher (SP).
1.1.2. Superblock Construction Protocol (SBCP) Module: Responsible for the correct participation through the lifecycle process of a slot. With this module, the sequencer is coordinated by the SP, being triggered to start a block production, include local transactions, participate in multiple SCP instances, submit a constructed block to the SP, and respond to roll back and L1 reorg events.
1.1.3. Framework Integration: The sequencer’s features to reach synchronous composability will be added on top of an existing library for optimized development. Particularly, it will be integrated to the OP Sequencer framework due to its wide adoption and readiness for market use.
1.1.4. Stress Testing: A collection of tests will validate the sequencer at corner cases situations, such as sequencer and SP failures and network partitions. These tests are essential for detecting possible protocol vulnerabilities and optimizations, ensuring that the protocol maintains correct behavior under all conditions.
1.1.5. Settlement Layer Module: In a network of rollups, while DA and settlement mechanisms enjoy improved features such as blob efficiency, they are also more complex and need a proper coordination between sequencers and the SP. This module will allow the sequencer to engage in the proofing process, either by producing validity proofs (ZKP) or participating in fraud proof challenges.
1.1.6. Malicious Behaviour Detection: A permissionless network require robustness against malicious actors. This requires the collaboration between honest parties to detect and report misbehaving nodes. The sequencer will follow protocol rules to identify malicious behaviour such as censorship, equivocation, and invalid block production.
1.2. Shared Publisher (SP) Node - The Company will develop an SP client for rollups, responsible for coordinating the rollups sequencers and publishing an aggregated super block to Ethereum L1. The SP node encompasses:
1.2.1. Synchronous Composability Protocol (SCP) Module: Responsible for managing the inclusion of a cross-chain transaction. With this module, the SP be able to control the duration of the protocol through a timing mechanism, terminating it in case it doesn’t succeed on time, and lead the sequencers by collecting vote messages and broadcasting a decided with the inclusion result.
1.2.2. Superblock Construction Protocol (SBCP) Module: Responsible for managing the lifecycle of a slot. With this module, the SP is able to start block construction, SCP instances, request rollups blocks to construct a superblock and trigger roll back and L1 reorg events.
1.2.3. Settlement Layer Module: This module will allow the SP to manage the settlement protocol. This consists of either requesting and aggregating ZK proofs from rollups and publishing an succinct constant-time verification proof for the whole superblock, or engaging in fraud proof games in case the validity of a superblock is challenged.
1.2.4. Malicious Behaviour Detection: Similarly as for sequencers, the SP have even more responsibilities of ensuring protocol adherence and preventing malicious actions from dishonest rollups. This will be provided by a set of protocol rules that the SP will follow to attribute faults and slash malicious participants.
1.2.5. Publishing: Common settlement and publishing is fundamental for the synchronous composability feature. The SP is responsible for this task and an efficient implementation will be developed to ensure state-of-the-art performance and lively state updates.
1.3. Continuous Node Maintenance and Development - As is the case with the DVT Network node, the Company will provide continuous node maintenance and development, ensuring alignment to up-to-date changes in industry standards, security best practices, and performance optimizations.
1.4. Documentation - The Company will provide comprehensive resources and guides for the comprehension on the protocol and its implementation, facilitating developer onboarding, external contributions, and community engagement.
2. SSV Smart Contract
2.1. Registry Contract - The Company will develop an L1 contract for managing information about network participants. This shall start with a permissioned model, in which only whitelisted participants can join the network. As the development progresses, it will evolve to a permissionless model, allowing any participant to join the network and, possibly, requiring staking for security purposes.
2.2. Superblock Contract - The Company will develop an L1 contract for managing the progression of rollups within the network, encompassing:
2.2.1. Efficient State Management: Optimized solutions will be researched and implemented for advancing the state through superblocks, a novel structure that aggregates blocks from multiple rollups, including metadata about the network chain and interoperability instances.
2.2.2. Blob Optimization: With many blocks, the network has the opportunity of making use of the full blob space. This will be explored to provide an enhanced experience for rollups through optimized blob occupancy and reduced costs.
2.3. Settlement Layer Module - The Company will develop an module in the L1 contract for the correct validation of a state progression. This requires a deep research on state-of-art techniques for optimized validity proof verification. Moreover, for scalability reasons, succinct proofs will be research so that the correctness of multiple rollups can be verified in constant time.
2.4. Framework Integration - The Company will develop the required contracts on top of existing frameworks for optimizing the development process. Namely, the set of contracts from the standard OP and OP-Succinct libraries will be forked and aligned as needed.
2.5. Unified Bridging - As an useful feature for attracting developers and users, the Company will develop a unified bridging contract that enables secure asset transfer between rollups of the network. Safety measures will be researched and implemented to ensure that the offered solution is compliant with best security practices.
2.6. Main dApps Use Cases - The Company will develop the necessary tools for showcasing important industry use cases that demonstrate the synchronous composability capabilities, such as a synchronous Uniswap integration, to potential developers and users.
3. SSV Tooling
3.1. Testnets - Maintaining an active and live testnet environment is essential for ensuring the stability, compatibility, and continuous development of any testnet. The testnet provides a controlled environment where new protocol versions can be deployed, tested, and refined before reaching mainnet, allowing for early feedback and issue resolution. The Company will focus on developing key capabilities including:
a. Testnet Deployment: The Company will ensure that all relevant smart contracts are deployed and maintained on Ethereum’s testnet, enabling developers to test and iterate before mainnet release.
b. Testnet: The Company will set up and maintain a testnet version of any Chain, allowing validators and developers to experiment with chain functionalities in a low-risk environment.
c. Developer Tooling Support: The Company will support relevant SDKs, APIs, and subgraphs that are compatible with the testnet, enabling developers to integrate and validate their implementations.
The testnet environment plays a crucial role in enabling developers, and validators to experiment, validate configurations, and test integrations before deploying to mainnet. This approach minimizes risks, accelerates innovation, and ensures that all protocol upgrades and enhancements undergo rigorous testing before production deployment, reinforcing SSV’s commitment to security, performance, and usability.
3.2. Tooling - To support developers and enhance adoption, the Company will build a comprehensive tooling suite any future protocol development of SSV:
a. Subgraph: The Company will work on Indexing and making contract events easily accessible.
b. SDK (TypeScript Library): The Company will provide a development toolkit that allows programmatic interaction with relevant smart contracts, supports fetching data, and enables other functionality
c. Technical Documentation & Example Projects: The Company will provide guides, resources, code samples, and best practices for developer integration
4. WebApp & Explorer
4.1. Webapp - The Company will develop a dedicated webapp that enables seamless interactions with the smart contracts, integrated into the existing SSV Webapp.
a. The Company will manage a friendly and intuitive interface for managing various protocol states.
b. The Company will enhance “Explorer” capabilities for exploring and showcasing interactions by developers
4.2. Compatibility - the Company will ensure the Webapp and Explorer fully support testnet environments, providing a seamless user experience for interacting with testnet deployments.
5. Incentivized Mainnet Program
With the evolution of SSV 2.0, the Incentivized Mainnet Program could be adapted to drive adoption and usage of the protocol. Similar to how the program supported the growth of the SSV Network, this iteration could focus on accelerating SSV 2.0 adoption, ensuring that developers are incentivized to explore and integrate with the new protocol. The Company will suggest:
5.1. Research & Design: The Company will conduct research on how to structure the next phase of the Incentivized Mainnet Program, aligning incentives with community adoption and network growth.
5.2. Proposed DAO Configuration: The Company will formulate and present a refined incentivization model to the DAO, ensuring that rewards are effectively allocated to encourage long-term participation and sustainability.
By aligning incentives with SSV 2.0’s growth strategy, the updated Incentivized Mainnet Program will help bootstrap adoption and drive engagement.
6. SSV Second Client
Support SSV Rollup Stack Second Client Implementation - As Sigma Prime develops the second DVT network node implementation, certain adjustments will be required for such an implementation to remain compatible with the newly built SSV 2.0. The Company will support Sigma Prime, if Sigma Prime is granted by the DAO to extend their support beyond the DVT Network Node implementation they are currently building. If Sigma Prime is not with such a grant, the Company will support any other team that is granted with implementing support for the second client implementation.
7. Formulation and Approval of Specifications for Development Roadmap
7.1. Specifications - The Company will define the technical specifications to guide development, backed by state-of-the-art distributed systems and security technologies.
8. Audits and Security
8.1. Contracts Audit - The Company will conduct a full security audit of the smart contracts, ensuring they function securely and efficiently while preventing vulnerabilities that could impact rollups sequencers, shared publishers and users.
8.2. Specifications Audit - The Company will conduct a review of the protocols specifications to validate protocol consistency, enforceability, and alignment with the proposed architecture.
9. Performance and Services Level Expectations
9.1. Ongoing Infrastructure Support and Maintenance - As the SSV Network scales, the demands for technical support and infrastructure maintenance increase proportionally. The Company’s engineering team is actively engaged in providing technical assistance to various teams building on the protocol. This includes resolving critical issues, optimizing network performance, and ensuring the reliability of participants operations. As the network’s user base expands, this support becomes increasingly complex, requiring constant vigilance and proactive troubleshooting to maintain system stability.
Future Iterations
Given purported direction mentioned in DIP-31 Amendment above, certain particulars may need to be amended in the future to further particularize the Compose technical details. If this proposal were to pass, the SSV Foundation would have the discretion to negotiate in the best interest of the DAO to accept or decline such particularizations from SSV.labs.
The SSV Foundation will have the ability to publicize these future amendments to the ssv.network DAO forum, if such publication doesn’t unduly affect the Compose brand, as decided by the SSV Foundation.
