LogoLogo
zkBob AppLinks & Resources
  • 🦹zkBob Overview
    • zkBob
    • Basic Concepts
      • Getting Started
      • Open-Source and Decentralized
      • Multichain Deployment
      • Usage Statistics
      • Use Cases
        • Employee Salary
        • Vendor Purchasing
      • Development Timeline
      • zk Privacy Solution Comparison
    • zkBob Pools
      • USDC Pool on Polygon (sunsets January 31, 2025)
      • USDC Pool on Optimism
      • ETH Pool on Optimism
      • USDT Pool on Tron (sunsets Oct 29, 2024)
    • Fees
      • Unspent note handling
    • Deposit & Withdrawal Limits
    • Compliance & Security
      • TRM Labs Integration
    • Conferences, Workshops, Videos
      • International Videos
    • Governance
    • BOB Stablecoin
    • zkBob FAQ
  • πŸ¦Έβ€β™‚οΈzkBob Application
    • UI Overview
    • Account Creation
      • Login to an existing account
      • Lost Password
      • Metamask / Web3 Wallet Warning
    • Deposits
    • Transfers
      • Multitransfers
    • Withdrawals
      • Native Token Conversion
    • Generate a Receiving Address
    • Optional KYC
    • zkBob Direct Deposits
    • Support ID
    • Payment Links
    • Integrated Services
    • Multilingual support
      • PortuguΓͺs
      • Русский
      • δΈ­ζ–‡
  • πŸ‘©β€βš•οΈTechnical Implementation
    • zkBob Application Overview
    • Deployed Contracts
    • Smart Contracts
      • zkBob Pool Contract
        • Transaction Calldata
      • Bob Token Contract
      • Verifier contracts
      • Operator Manager Contract
        • Mutable Operator Manager
      • Voucher (XP) Token Contract
    • Accounts and Notes
      • Accounts
      • Notes
    • Relayer Node
      • Relayer Operations
      • Optimistic State
      • REST API
    • zkBob Keys
      • Address derivation
      • Ephemeral keys
    • zkSNARKs & Circuits
      • Transfer verifier circuit overview
    • zkBob Merkle Tree
      • The Poseidon Hash
    • Elliptic Curve Cryptography
    • Transaction Overview
      • Common Structure
      • Memo Block
        • Memo Block Encryption
      • Transaction Types
      • Nullifiers
      • Signing a Transaction
      • The Transaction Lifecycle
    • Client Library SDK
      • Configuration
        • Initializing the client
          • Client Configuration
        • Attaching a User Account
          • Account Configuration
        • Switching Between Pools
      • Account-less Mode Operations
        • Converting Token Amounts
        • Transaction Fees
        • Transaction Constraints
        • Using the Delegated Prover
        • Getting the State
        • Gift Cards
        • Client Library Status
        • Helpers
        • Versioning
      • Full Mode Operations
        • Balances and History
        • Shielded Addresses
        • Account State
        • Fee Estimations
        • Transaction Configuration
        • Sending Transactions
        • Transaction Maintenance
        • Direct Deposits
        • Gift Cards Maintenance
        • Ephemeral Deposits
        • Forced Exit
        • Other Routines
      • Common Types
      • Full Functions List
      • Utilities
  • πŸ‘©β€πŸ«Deployment
    • Trusted Setup Ceremony
    • Contract Deployment
    • Relayer Subsystem
  • πŸ‘·β€β™‚οΈRoadmap
    • On the Roadmap
    • Exploratory Features
      • XP (Experience Points)
        • XP-based Auctions
      • Multi-chain Custom Rollup Deployment
      • Round-robin Operator Manager
      • Compounding
  • πŸ§‘β€πŸ’»Jobs
    • Zero-Knowledge Researcher & Protocol Developer
  • 🧩Resources
    • Visual Assets
    • Hackathons
      • zkBob Cloud
    • Release Notes
      • October 11, 2023
      • July 13, 2023
      • June 13, 2023
      • March 28, 2023
      • January 30, 2023
      • January 16, 2023
      • January 2, 2023
      • Releases 2022
    • Security Audit
    • Github
    • Link tree
Powered by GitBook
On this page
  • The operator manager life-cycle
  • Getting the current relayer
  • The contract maintenance state

Was this helpful?

  1. Roadmap
  2. Exploratory Features

Round-robin Operator Manager

Round-robin relayer selection

Non-production feature

The Round-Robin Operator Manager may be implemented as a future use case. It has several disadvantages including high gas consumption for relayers (even when idle) and requires additional improvements.

An operator and relayer are equivalent entities in the contracts layer.

The current zkBob implementation assumes that only a single relayer can interact with the pool contract at any given time. An approach is needed to select a single relayer for each time interval within a multiple-relayers configuration.

The simplest way to do this is to select a relayer from a list in a round-robin manner. We implement this method in the RoundRobin contract.

The relayer list is managed by the contract owner which can add or remove the relayer at any time. The contract owner should transfer the operator manager contract to the maintenance state to change the list of approved relayers. In this state the main functionality is disabled and all regular methods are reverted.

Relayer list management

Only strictly approved relayers are accepted to avoid malfunction operations. The relayer should be stable and available through public networks and it should have a quality communication link. The relayer should have a maintainer who is available to fix operating issues.

TODO: Develop / describe relayer approval procedure

The operator manager life-cycle

The operator manager contract lifetime is divided by time slots. Each slot contains a fixed amount of underlying blockchain blocks. It starts with the Genesis slot (the first 1000 blocks after contract deployment). The Genesis slot's purpose is to configure the contract by the owner and prepare relayers for operation. In that block the owner should create an operator list with at least one entry.

Each relayer should periodically inform the operator manager contract that it's ready to operate with the Pool. To do that a relayer should invoke the claim()contract method. The claim received in the current slot is intended for the next one. If the relayer does not provide a claim for the specified block it will be ignored in the round-robin selection and the next available one will be used. This approach is intended to decrease the probability of unavailable relayers.

If there are no claims for the current slot, the last operator that sent a claim will be selected. So it's not necessary for operator to send claims for the each slot in the single relayer configuration.

The regular slot

The default slot size is 120 blocks. It can be changed by the contract owner with the setSlotSize() method in the maintenance state.

Please keep in mind that selection sequence is changed after the slot size modification

The current operator index iii (within an operator list with the length NNN) for the each slot with index SiS_iSi​ is calculated in round-robin manner:

i=(Siβˆ’1)modNi = (S_i - 1) \text{mod} Ni=(Siβ€‹βˆ’1)modN

The Genesis slot has the index 0 so the operator selection during that slot is unavailable. The resulting index iiican be changed in the interval [0,Nβˆ’1][0, N-1][0,Nβˆ’1] inclusively.

In the picture above you can explore the selection mechanism. After contract deployment the owner adds three approved relayers (named RL-1, RL-2 and RL-3). The first and the second relayer claimed for the slot 1 during Genesis slot, so the first one will be selected as an active operator.

The third relayer becomes available only in slot 2, so his first claim is intended for slot 3. Fortunately the third operator should be selected in slot 3 exactly (according to the round-robin scheme). So it's become an active relayer in slot 3.

During slot 3 the first relayer (RL-1) has failed, and the operator manager contract didn't receive a claim from it. That's why in slot 4 the RL-1 has been ignored and the next claimed operator (RL-2) has been selected.

In the 4 the third relayer (RL-3) has also failed, so only the single claim has been received from RL-2. In slot 5 RL-2 should be selected according to the round-robin scheme.

Let's imagine that RL-2 has decided to stop claim sending after slot 4. This led to an absence any claims for slot 6. In that case the last claimed operator (RL-2) will be selected for the next slot.

Getting the current relayer

Anyone can invoke the following contract methods to retrieve the current relayer properties in the normal state:

  • operator() will return the current operator blockchain address. In the maintenance state the method call will be reverted. If there are no selected relayers for the current slot, this method returns address(0) [To be discussed: return 0 or revert?]

  • operatorURI() will return the current operator's endpoint URL (string).

  • operatorName() will return the current operator name (string).

  • amIOperator() will return a boolean value indicating that a message sender is an active operator at that time.

The contract maintenance state

If the contract owner intends to make some changes the contracts should be changed to a maintenance state. In this state all regular method calls are reverted and the operator manager accepts the service calls only. After maintenance is complete, the contract should be returned in the regular state to proceed a normal flow. Changing the contract's state is performed by the method setMaintenance(bool)

In the maintenance state the following service methods are available:

  • addOperator(stringname, addressaddr, stringendpoint) will add a new operator with the specified name, blockchain address and URL endpoint.

  • removeOperator(addressaddr) will remove the operator with the specified address. Please note that the last operator in the list will be relocated to the vacant place.

  • setSlotSize(uint32 blocks) will change slot size (specified in blocks). The number of blocks should be greater than 0.

PreviousMulti-chain Custom Rollup DeploymentNextCompounding

Last updated 2 years ago

Was this helpful?

πŸ‘·β€β™‚οΈ
Relayer selection scheme