EigenLayer AVSOps

Deploying AVS comes with challenges: they require isolated, secure environments to operate reliably and efficiently. That's where Vistara’s Hypercore steps in, offering powerful, flexible virtualization solutions.

Hypercore is a Hypervisor Abstraction Layer. It allows developers to abstract away deployment complexities, thanks to our "Hardware-as-Code" approach. Just write a hac.toml file specifying hardware needs, and Hypercore handles the rest, ensuring your AVS is up and running swiftly and securely.

Hypervisor abstracts hardware and Hypercore abstracts Hypervisors. With our unified API, Hypercore interfaces with various hypervisors to simplify and speed up the deployment of programmable environments and AVSs. It's as quick as launching a web app but ensures that each AVS operates in a secure and scalable virtual space. With this, AVS developers do not need to worry about manually deploying AVSs to their hardware or on a decentralized computing network.

Currently, we support KVM hypervisors like Firecracker and Cloud-Hypervisor to accommodate the most common use cases.

We propose a standardized protocol that leverages Vistara's hypercore (hypervisor abstraction layer) for faster, secure, and efficient deployment of AVSs. This standard would streamline the process of provisioning hardware resources as defined in the hac.toml file and securely deploying and operating AVS containerd (Industry standard container runtime) images.

Specification Proposal for AVS Deployment Using Vistara Hypercore:

  1. Resource Specification and Provisioning:

    • The operator receives AVS specifications through hac.toml defining CPU, memory, storage, and network parameters.

    • The Vistara Hypercore parses these specifications and provisions the underlying resources within a MicroVM or optional TEE environment based on the AVS's security requirements.

  2. Containerized AVS Deployment:

    • AVS spacecores are packaged as containerd images, incorporating security and network configurations.

    • Vistara Hypercore deploys these images within the provisioned MicroVMs or TEEs, enforcing strict isolation.

  3. AVS Operations:

    • Each AVS spacecore operates within its secure environment, with networking configured to allow necessary off-chain and on-chain interactions.

    • The lifecycle of each AVS, including updates and scaling, is managed through Vistara's service manager interface.

  4. Security and Isolation:

    • Isolation is achieved via virtualization at the hardware level, with additional security layers provided by the chosen container runtime.

    • The specification includes monitoring for anomalous behavior to detect and respond to potentially malicious code.

  5. Observability Sidecar Implementation:

    • A sidecar container runs alongside the AVS container, within the same MicroVM.

    • It gathers operational metrics and logs and can be standardized across different AVS deployments.

    • Operators can use this for real-time monitoring and incident response.

    • Hypercore monitors the resource utilization and performance of the deployed AVS instances running within the hypervisor infrastructure.

    • Based on predefined scaling policies or real-time demand, Hypercore dynamically scales the hypervisor infrastructure to ensure optimal performance and resource allocation for the AVS instances.

  6. Signature and Attestation Standards:

    • AVS operations that require cryptographic attestations adhere to specified signature schemes such as BLS or ECDSA.

    • AVS developer ensures the integrity and confidentiality of signature keys and provides a standard mechanism for generating and storing attestations.

  7. Standardization and Community Governance:

    • A clear and transparent process for updating and governing the specification standard is established, encouraging community feedback and contributions.

Sample Standard Protocol Definition:

apiVersion: vistara.eigenlayer/v1
kind: AVSSpaceCore
metadata:
  name: spacecore-sample
spec:
  resources:
    cpu: "4"
    memory: "8Gi"
    storage: "100Gi"
  virtualization:
    type: "MicroVM" # Other types can be TEE, Container, etc.
    provider: "KVM" # Can be Unikernel, Intel SGX, TDX, Kata, Firecracker, etc.
    criteria:
      security: "high"
      performance: "standard"
  networking:
	  bandwidth_limit: 10 # in Gpbs
	  ingress: "1Gbps"
    egress: "1Gbps"
	  network_type: "public"
	  inbound_ports:
		  HTTP: 80
		  https: 443
  deployment:
    image: "registry/path/to/spacecore:image"
  security:
    attestation: "BLS" # Other options can be ECDSA, etc.
    isolation: "enforced via SELinux/AppArmor/seccomp"
  observability:
    sidecar: true
    monitoring: "Prometheus/Grafana"
    logging: "Loki/Fluentd/ELK"
  operations:
    updateStrategy: "RollingUpdate"
    scaling: "HorizontalAutoScaling"
  failover:
    strategy: "auto-recovery"

TOML:

apiVersion = "vistara.eigenlayer/v1"
kind = "AVSSpaceCore"

[metadata]
name = "spacecore-sample"

[spec.resources]
cpu = "4"
memory = "8Gi"
storage = "100Gi"

[spec.virtualization]
type = "MicroVM"
provider = "KVM"

[spec.virtualization.criteria]
security = "high"
performance = "standard"

[spec.networking]
bandwidth_limit = 10
ingress = "1Gbps"
egress = "1Gbps"
network_type = "public"

[spec.networking.inbound_ports]
HTTP = 80
https = 443

[spec.deployment]
image = "registry/path/avs-spacecore:latest"

[spec.security]
attestation = "BLS"
isolation = "enforced via SELinux/AppArmor/seccomp"

[spec.observability]
sidecar = true
monitoring = "Prometheus/Grafana"
logging = "Loki/Fluentd/ELK"

[spec.operations]
updateStrategy = "RollingUpdate"
scaling = "HorizontalAutoScaling"

[spec.failover]
strategy = "auto-recovery"

  1. The AVS developer defines the AVS code, dependencies, and requirements using the hac.toml specification format.

  2. The AVS and its hac.toml specification are registered with EigenLayer.

  3. The hac.toml is registered with the Operator.

  4. Hypercore provisions and configures the appropriate hypervisor infrastructure based on the hac.toml specification.

  5. Hypercore monitors the resource utilization and performance of the deployed AVS instances and scales the hypervisor infrastructure accordingly.

Proposed Workflow:

mermaid flow
sequenceDiagram
    participant O as Operator
    participant H as Vistara Hypercore
    participant V as Vistara Service Manager
    participant S as AVSSpaceCore
    participant T as TaskManager
    participant A as Aggregator

    O->>H: Submit 'hac.toml'
    H->>V: Provision Resources in <br/>MicroVM or Unikernel
    V->>S: Deploy Containerd Image
    S->>S: Initialize & Run AVS
    T->>S: Interact with AVS
    T->>O: New task created
    O->>S: Run task
    S->>+A: Aggregator.ProcessSigned TaskResponse
    A->>A: Verify Signature
    A->>S: Aggregate Signature
    A->>S: Quorum threshold reached
    A->>T: Send response

In this workflow:

  • Operators are responsible for submitting the AVS configuration and the container image.

  • Vistara Hypercore provisions the necessary resources in a MicroVM or Unikernel as per the hac.toml.

  • Vistara Service Manager handles the deployment of the containerd image within the virtualized environment.

  • AVSSpaceCore represents the deployed AVS

  • TaskManager sends a new task to the AVS (AVSSpacecore)

  • The Operator runs the task and sends the response to Aggregator

  • The Aggregator verifies signature and, once the quorum threshold is reached, sends the response.

Challenges such as AVS failure, security breaches, and resource allocation will be mitigated by the protocol's inherent design, leveraging virtualization for isolation and containerization for secure and reproducible deployments. The observability component ensures that any issues are quickly identified and addressed.

The goal is to align with EigenLayer's vision while providing robust and secure virtualization capabilities for AVSs.

Edge Cases to Consider:

  • Resource Contention: Multiple AVS instances could compete for limited hardware resources.

  • Network Isolation: Ensuring that network traffic between AVSs remains isolated.

  • Security Vulnerabilities: AVS code could potentially contain vulnerabilities or malicious code.

Container Packaging and Deployment: Vistara would utilize containerization technologies to package and deploy each AVS. Containers are inherently portable and provide a consistent environment for the application. The deployment process would involve:

  1. Pulling the container image from a registry.

  2. Running the container within the MicroVM with specified environmental variables and port mappings.

  3. Binding storage volumes as defined in the hac.toml.

Technical Challenges and Solutions:

  • Challenge: Ensuring robust security in a multi-tenant environment.

    • Solution: Use strict access control policies, perform regular security audits, and implement mandatory security scanning for container images.

  • Challenge: Handling failures without affecting other services.

    • Solution: Implement health checks and auto-recovery mechanisms for AVS containers, and use orchestration tools for container management.

  • Challenge: Deploying and managing a large number of AVS instances.

    • Solution: Automate deployment with CI/CD pipelines and manage instances with Kubernetes or similar orchestration platforms.

PreviousHow do we implement it?NextSecure Enclaves

Last updated