Nexus Network

Problem statement

Ethereum made its monumental shift to Proof of Stake in September ’22. The enabling of ETH withdrawals in April’23 has resulted in large inflows of ETH to get staked to the network. Even after that, the amount of ETH staked is 22%, much lower than other Proof of Stake networks. While the current stance by the Ethereum development team is to reduce the growth of staked ETH because of latency and security concerns, the longer term movement should be towards staking a large part of the network to increase the cost of attack on Ethereum.

Rollups have had a tremendous growth story over the past 2 years, driven by the rollup centric roadmap for Ethereum. This has led to a large movement of ETH to rollups moving more than 1.5% of ETH supply. We expect the number to grow to over 20% in the next few years. The ETH deposited to rollups gets locked in rollup bridges that results in a reduction of the security of the network as well as capital inefficiency.

Nexus Network: Staking infrastructure for rollups

Nexus Network envisions to become the economic layer for rollups. Using our staking infrastructure, Rollups can stake the ETH locked in their bridges and earn continuous stable staking returns. Nexus Network is building on top of SSV Network using their Distributed Validator Technology (DVT) to minimise validator centralisation and slashing risks without incurring any additional development time or resources. To enable this, the staking infrastructure provides the following features to rollups -

1. Pluggable staking infrastructure - Rollups can integrate with Nexus Network within a few minutes by calling Nexus contracts
2. Customisable staking limits - Rollups can stake a proportion of ETH locked in the bridge. For example, setting the staking limit to 10% stakes 10% of ETH on the bridge. Nexus contracts will continuously monitor the amount locked in the bridge and stake/unstake assets based on the staking limit
3. One stop validator management - Nexus Network does not put any additional responsibility on the rollup team. Rollup teams can share their preferred validator set and Nexus architecture will manage the staking accordingly

Security-first approach

The principles driving the Nexus Network staking infrastructure design are security, reliability, and decentralisation. The major differentiators in the Nexus Network architecture -

1. Non-custodial solution - We have built a non-custodial solution for rollups that sends ETH directly to validators created through the SSV network. The withdrawal address for validators is set as the rollup bridge contract itself so that any asset withdrawn from the Ethereum network goes directly to the bridge contract. The rewards from the staking returns are transferred to the rollup admin address, removing the involvement of Nexus Network in the entire asset flow

2. Distributed Validator Technology (DVT) - The Ethereum validator design allows users to run only one instance of the validator to avoid the risk of double signing. However, this centralises the risk as there is no backup if the validator fails due to technical or client errors. DVT solves this by allowing validators to split their keys across multiple nodes, which collectively perform all the validator tasks. DVT only requires a portion of validators to sign the transaction, creating redundancy in case one of the nodes goes down reducing the likelihood of missed blocks and slashing risks

How does Nexus Network work?

Nexus Network provides a no-hassle product to rollups that they can plug into the rollup bridge and earn continuous revenue. The product has three major components -

1. Nexus package for rollup bridges - Rollups include the Nexus package in their bridge contracts. This package enables three functions - a. Enable flow of assets from rollup bridge to Ethereum for staking b. Update rewards earned from staking c. Allows rollup to claim the earned rewards

2. Nexus contracts - Nexus contracts handle all the validator operations including creation and management of validators, and validator performance monitoring. The contracts interface with the DVT solution from SSV network for distributed validator key generation

3. Off chain bots - These bots are required to communicate between the product components - Ethereum consensus chain to Nexus contracts, Nexus contracts to rollup bridge contract

Rollup registration

To start working with Nexus Network, rollups perform a one-time registration. We have simplified the registration process allowing rollups to register through a few package imports and contract calls. These are the steps involved -

1. Importing Nexus package in the bridge - Rollup imports Nexus package that enables the three functions mentioned in previous section to allow for assets to flow from rollup bridge and back

Demo: We have imported the Nexus package to three rollup bridge contracts, out of which two have been deployed on Goerli testnet (Polygon zkEVM and Scroll)

1. Whitelisting of rollup admin contract - Rollup team communicates with Nexus to whitelist an admin address. This address can be an EOA or a multisig. The whitelisting process happens only after the rollup has imported the Nexus package in the bridge

Demo: For the demo, we have kept the whitelisting process open so that anyone can whitelist their address as the admin address

1. Registering the rollup on Nexus - Once the rollup admin address is whitelisted, it can perform a contract call on Nexus contracts to register the rollup. This call includes parameters on the staking limit (this determines the proportion of ETH on the rollup bridge that will be staked) and the node operator set that rollup wants to run. If the rollup does not have a preference, Nexus Network will automatically select the best performing node operator set

Demo: Admin can put the address of any of the three rollup bridges deployed on Goerli in step 1. It then sets a staking limit and selects a cluster (set of node operators deployed on the SSV network). Performing this contract call registers the rollup

Continuous operations

Once the rollup is registered and staking limit is set, the Nexus Network automatically proceeds with validator creation and staking of ETH. The process works as follows -

1. Rollups define the proportion of ETH on the rollup bridge to be staked
2. Nexus Network continuously tracks the bridge balance and stakes ETH accordingly
3. Nexus Network takes care of the validator creation and monitoring with no extra effort required by the rollup contributors

Demo: This is an automated process in the demo

Changing staking ratio

Rollups can change the staking limit at any time through a contract call from the admin address. This results in staking of more ETH if staking limit is increased, or unstaking from network and transfer of assets to the rollup bridge contract if the staking limit is reduced

Demo: Rollups can change the staking limit using the “Admin View” on UI

Unplug from Nexus Network

The rollup can unplug from Nexus Network altogether by changing the staking ratio to 0%. This will unstake all the assets and return them to the rollup bridge contract

Demo: This feature is not enabled in the demo as unstaking ETH on Goerli takes some time. This will result in some accounting issues when we allow users to perform different contract calls using the same rollup contract (as we have done in the permissionless demo). In the testnet/mainnet deployment case, one rollup bridge contract will have only one admin address

To make the project work, following functionalities were developed during hackathon and others were used as it is or with a few tweaks:

1. From scratch: These all repos were made from scratch

a. Frontend: Nexus Network's front end leverages Next.js 13 for cutting-edge web development. It combines TypeScript for type safety, Material UI and Tailwind CSS for design, Rainbow Kit Wallet for secure wallet interactions, Ethers.js for Ethereum blockchain integration, Anime.js for animations, and the Graph Protocol for efficient data queries. This tech stack ensures a user-friendly and visually appealing front end. It helps the rollups to register and monitor their system registered with nexus network.

Repo: https://github.com/Nexus-2023/nexus-dashboard Deployed link: https://nexus-dashboard-omega.vercel.app/

b. Subgraph: We used subgraphs to store the events from the Nexus Contracts and fetch data for frontend and off-chain bots. Repo: https://github.com/Nexus-2023/subgraph Deployed link: https://thegraph.com/studio/subgraph/nexus/playground

1. Network Integrations: For hackathon we integrated the following rollups -

a. Scroll: We changed the L1Messenger contract for Scroll where the ETH bridged to the rollup is stored Repo: https://github.com/Nexus-2023/scroll/blob/nexus/ethOnline/contracts/src/L1/L1ScrollMessenger.sol

Deployed Contracts: Bridge: https://goerli.etherscan.io/address/0x192BFB9F22c86e9Fd6da506Ac8c7E4CF71d5Da4d#code Messenger: https://goerli.etherscan.io/address/0xcf6937e3d52060382725588f370f37f08fa0d158#code

b. Polygon ZkEVM: We made changes to the LxLy bridge which stores the ETH bridged to the rollup Repo: https://github.com/Nexus-2023/zkevm-contracts/blob/ethOnline/contracts/PolygonZkEVMBridge.sol

Deployed Contracts: https://goerli.etherscan.io/address/0x71bD2471B67710B294e527cEc73177140D742dB2#code

c. Mantle: We made changes to the L1StandardBridge contract which stores the ETH bridged to the rollup Repo: https://github.com/Nexus-2023/nexus-mantle/tree/nexus/ethOnline

Due to time and test ETH constraints, the Mantle integration testing was only done on local and could not be performed on Goerli testnet

For integration with all the partner protocols, their development scripts were changed. Most of the changes are hacky as all these scripts had breaking changes and some libraries were missing. To make it work we commented some code, made some changes to make things fit to our requirement

1. Changes in existing Nexus contracts: These were pre-existing repos and minor changes were made to integrate the newly built system with the existing repos -

a. Off-chain bot: We implemented code for fetching data from subgraph which was deployed during the hackathon. The off-chain bot ensures that the amount of ETH staked is in line with the staking limit set by the rollup. For this, it keeps a track of ETH balance in the bridge contracts as well as monitors the amount to ETH staked to validators and accordingly creates/withdraws validators. It pieces together the SSV DVT technology and ETH staking-deposit-cli to enable this functionality Repo: https://github.com/Nexus-2023/off-chain-oracles/tree/nexus/ethOnline

b. Nexus-Contract: No changes were made in this repo apart from deployment. It is the backbone of Nexus Network combining everything together. Repo: https://github.com/Nexus-2023/Nexus-Contracts/tree/nexus/ethOnline Deployed Contract: https://goerli.etherscan.io/address/0xe3c0f0089fb0c38c7dd2e780b9309419e1decd77#code

The major effort during the hackathon was in piecing together the entire architecture so that everything flows well end-to-end. The different components and their functionalities -

1. Nexus-Contract is the central point that facilitates the entire infrastructure. It enables the registration of rollups, submission of validator keys, and SSV keyshares

2. Subgraph catches all the events emitted by Nexus Contract and stores them. The subgraph can be called by anyone for a permissionless view of the current state of the project components

3. Off-chain bots keep a track of all the rollups registering with Nexus. They determine the number of validators required, and generate the keys and keyshares depending on the staking limit set by individual rollups. Staking infrastructure is separately managed for each rollup client

4. The frontend enables all rollups to register their bridge contract, modify the staking limit, and track the performance of all the validators associated with the rollup

The validators created during the deployment process and their corresponding activated Cluster on SSV are -

Polygon zkEVM validator - https://goerli.beaconcha.in/validator/593736 Polygon zkEVM SSV validator - https://goerli.explorer.ssv.network/validators/893e5710efd39ab5b543a1f3555dd57a19a527030995d90fdd7c9bf20b1e7eb60686d03708cd84b2953af10c95a3ae3d

Scroll validator - https://goerli.beaconcha.in/validator/594090 Scroll SSV validator - https://goerli.explorer.ssv.network/validators/a530a93d276e48549ebeddb78b16f4dd893d0b04b6b8f646dc2d6f807e5ec80863e1157cb4b4adb683f56fcd571c2abc