diff --git a/pages/developers/_meta.ts b/pages/developers/_meta.ts index f4cf91f..f505ad1 100644 --- a/pages/developers/_meta.ts +++ b/pages/developers/_meta.ts @@ -13,6 +13,7 @@ const meta: Meta = { }, "blueprint-sdk": "Introduction", "blueprint-contexts": "Contexts", + "blueprint-runner": "Blueprint Runner", "p2p-networking": "P2P Networking", "tangle-avs": "Build a Tangle Blueprint", "eigenlayer-avs": "Build an Eigenlayer AVS", diff --git a/pages/developers/blueprint-contexts/_meta.ts b/pages/developers/blueprint-contexts/_meta.ts index 87d7cae..e37dc8f 100644 --- a/pages/developers/blueprint-contexts/_meta.ts +++ b/pages/developers/blueprint-contexts/_meta.ts @@ -2,10 +2,11 @@ import { Meta } from "nextra"; const meta: Meta = { introduction: "Introduction to Contexts", - "keystore-context": "Keystore Context", + "eigenlayer-context": "Eigenlayer Context", "evm-provider-context": "EVM Provider Context", + "keystore-context": "Keystore Context", + "services-context": "Services Context", "tangle-client-context": "Tangle Client Context", - "eigenlayer-context": "Eigenlayer Context", }; export default meta; diff --git a/pages/developers/blueprint-contexts/eigenlayer-context.mdx b/pages/developers/blueprint-contexts/eigenlayer-context.mdx index dea815a..45cfe32 100644 --- a/pages/developers/blueprint-contexts/eigenlayer-context.mdx +++ b/pages/developers/blueprint-contexts/eigenlayer-context.mdx @@ -33,10 +33,10 @@ The `EigenlayerContext` trait provides access to core Eigenlayer services and fu - Monitor stake across different quorums ## Using the Context @@ -45,37 +45,42 @@ The `EigenlayerContext` trait provides access to core Eigenlayer services and fu First, define your context struct that implements the `EigenlayerContext` trait: -{/* TODO: Add URL */} - -### 2. Use the Context in Jobs +### 2. Implement methods for the context -You can then use this context in your jobs to access Eigenlayer functionality: +You can implement methods for the context to provide custom functionality: + + + +### 3. Use the Context in Jobs -{/* TODO: Add URL */} +You can then use this context in your jobs to access Eigenlayer functionality: -### 3. Instantiate the Context +### 4. Instantiate the Context Finally, instantiate your context in your main runner: -{/* TODO: Add URL */} - diff --git a/pages/developers/blueprint-contexts/evm-provider-context.mdx b/pages/developers/blueprint-contexts/evm-provider-context.mdx index 410061c..26e12a9 100644 --- a/pages/developers/blueprint-contexts/evm-provider-context.mdx +++ b/pages/developers/blueprint-contexts/evm-provider-context.mdx @@ -13,9 +13,9 @@ The `EvmInstrumentedClientContext` trait provides a standardized [alloy-rs](http The `EvmInstrumentedClientContext` trait provides access to an EVM provider: @@ -26,9 +26,9 @@ The `EvmInstrumentedClientContext` trait provides access to an EVM provider: First, define your context struct that implements the `EvmProviderContext` trait: @@ -37,8 +37,8 @@ First, define your context struct that implements the `EvmProviderContext` trait You can then use this context to access EVM provider parameters: diff --git a/pages/developers/blueprint-contexts/introduction.mdx b/pages/developers/blueprint-contexts/introduction.mdx index 7fcc33a..b43e5f9 100644 --- a/pages/developers/blueprint-contexts/introduction.mdx +++ b/pages/developers/blueprint-contexts/introduction.mdx @@ -4,7 +4,7 @@ title: Introduction to Contexts ## What is a Context? -In the Gadget SDK, a Context holds utilities and dependencies that a job may need that aren't direct inputs. Think of it as a container for all the external resources and services your job requires to function. +In the Blueprint SDK, a Context holds utilities and dependencies that a job may need that aren't direct inputs. Think of it as a container for all the external resources and services your job requires to function. A Context can include various elements such as: diff --git a/pages/developers/blueprint-contexts/keystore-context.mdx b/pages/developers/blueprint-contexts/keystore-context.mdx index 93b4a2b..f78a6fd 100644 --- a/pages/developers/blueprint-contexts/keystore-context.mdx +++ b/pages/developers/blueprint-contexts/keystore-context.mdx @@ -19,9 +19,9 @@ The `KeystoreContext` trait provides access to a `Keystore` that implements the - Key Import/Export - Import existing keys and export key data @@ -32,9 +32,9 @@ The `KeystoreContext` trait provides access to a `Keystore` that implements the First, define your context struct that implements the `KeystoreContext` trait: @@ -43,8 +43,8 @@ First, define your context struct that implements the `KeystoreContext` trait: You can then use this context to access the keystore and perform key operations: diff --git a/pages/developers/blueprint-contexts/services-context.mdx b/pages/developers/blueprint-contexts/services-context.mdx new file mode 100644 index 0000000..4bc36b8 --- /dev/null +++ b/pages/developers/blueprint-contexts/services-context.mdx @@ -0,0 +1,49 @@ +--- +title: Services Context +--- + +import GithubFileReaderDisplay from '/components/GithubFileReaderDisplay'; + +# Services Context + +The `ServicesContext` trait provides a standardized interface for interacting with the Tangle network in your Blueprint through a Subxt `OnlineClient` with a PolkadotConfig. + +## Overview + +The `ServicesContext` trait provides access to a Subxt client that enables: + +- Fetching Blueprints - Retrieve Blueprints by ID +- Querying Blueprints - Query Blueprints for an operator +- Retrieving Blueprint Owners - Return the Owner for a Blueprint +- Fetching Service Operators - Return a list of operators for a service + + + +## Using the Context + +### 1. Define Your Context + +First, define your context struct that implements the `ServicesContext` trait: + + + +### 2. Access Services Client Functionality + +You can then use this context to access the services client and interact with Tangle services: + + diff --git a/pages/developers/blueprint-contexts/tangle-client-context.mdx b/pages/developers/blueprint-contexts/tangle-client-context.mdx index 065f272..1b36e26 100644 --- a/pages/developers/blueprint-contexts/tangle-client-context.mdx +++ b/pages/developers/blueprint-contexts/tangle-client-context.mdx @@ -18,9 +18,9 @@ The `TangleClientContext` trait provides access to a Subxt client that enables: - RPC Calls - Make direct RPC calls to Tangle nodes @@ -31,9 +31,9 @@ The `TangleClientContext` trait provides access to a Subxt client that enables: First, define your context struct that implements the `TangleClientContext` trait: @@ -42,8 +42,8 @@ First, define your context struct that implements the `TangleClientContext` trai You can then use this context to access the Subxt client and interact with Tangle: diff --git a/pages/developers/blueprint-runner/_meta.ts b/pages/developers/blueprint-runner/_meta.ts new file mode 100644 index 0000000..823f7e1 --- /dev/null +++ b/pages/developers/blueprint-runner/_meta.ts @@ -0,0 +1,13 @@ +import { Meta } from "nextra"; + +const meta: Meta = { + introduction: "Introduction", + jobs: "Jobs", + routers: "Routers", + producers: "Producers", + consumers: "Consumers", + "background-services": "Background Services", + building: "Building a Blueprint Runner", +}; + +export default meta; diff --git a/pages/developers/blueprint-runner/background-services.mdx b/pages/developers/blueprint-runner/background-services.mdx new file mode 100644 index 0000000..9ba37ba --- /dev/null +++ b/pages/developers/blueprint-runner/background-services.mdx @@ -0,0 +1,79 @@ +--- +title: Background Services +--- + +import GithubFileReaderDisplay from '/components/GithubFileReaderDisplay'; + +# Background Services + +Background services are optional components in the [Blueprint Runner](/developers/blueprint-runner/introduction) architecture that run continuously to support the operation of your Actively Validated Service (AVS). This document explains how background services work, how to configure them, and best practices for implementation. + +## What are Background Services? + +Background services refer to any long-running processes that operate independently of job execution. They: + +1. Run continuously in the background +2. Can perform periodic or ongoing tasks +3. Might maintain state or connections +4. Support the overall operation of the Blueprint Runner + +Unlike job handlers that execute in response to specific requests, background services operate autonomously to provide supporting functionality. + +## Common Use Cases + +Background services could be used for various purposes in Blueprints, with the following being only a few examples: + +### Data Collection and Aggregation + +Services that collect and aggregate data, such as an aggregator that submits aggregated signatures to a Blockchain. + +### Monitoring and Health Checks + +Services that monitor the state of something, such as a health checker that verifies that a Blueprint is running. + +## Background Service Configuration + +Background services are typically configured in the `main.rs` file of your Blueprint binary, when building the Blueprint Runner. The configuration involves: + +### Basic Background Service Setup + +The only requirement for a background service is that it implements the `BackgroundService` trait: + + + +With a background service defined, it is passed into the Blueprint Runner's builder as producers and consumers are: + + + +For some background services, it may be necessary to add some sort of cleanup code that runs when the Blueprint Runner shuts down. This can be done in the `with_shutdown_handler` method seen in the above code. This specific example just prints a message, but it might end a background process gracefully. + +## Integration with Other Components + +Background services work closely with other Blueprint Runner components: + +- **Routers**: Background services may provide support for [routers](/developers/blueprint-runner/routers), such as caching or state management +- **Producers**: Background services can support [producers](/developers/blueprint-runner/producers) by maintaining connections or monitoring event sources +- **Consumers**: Background services can assist [consumers](/developers/blueprint-runner/consumers) with resource management or periodic tasks + +## Next Steps + +Now that you understand background services, it might be helpful to take a look at: + +- [Routers](/developers/blueprint-runner/routers) - How to direct job calls to appropriate handlers +- [Producers](/developers/blueprint-runner/producers) - How to capture and process events +- [Consumers](/developers/blueprint-runner/consumers) - How to handle job results +- [Building a Blueprint Runner](/developers/blueprint-runner/building) - Step-by-step guide to building your own Blueprint Runner + +## Conclusion + +Background services are powerful components that enhance the capabilities of your Blueprint Runner by providing continuous support operations. By implementing well-designed background services, you can build more robust, efficient, and feature-rich Blueprints. diff --git a/pages/developers/blueprint-runner/building.mdx b/pages/developers/blueprint-runner/building.mdx new file mode 100644 index 0000000..6cb3bd3 --- /dev/null +++ b/pages/developers/blueprint-runner/building.mdx @@ -0,0 +1,179 @@ +--- +title: Building a Blueprint Runner +--- + +import GithubFileReaderDisplay from '/components/GithubFileReaderDisplay'; + +# Building a Blueprint Runner + +This guide provides a step-by-step approach to building a Blueprint Runner, the primary component of a Blueprint. + +## Prerequisites + +Before you start building your Blueprint Runner, ensure you have: + +1. [Rust](https://www.rust-lang.org/tools/install) installed +2. [Tangle CLI](../cli/installation.mdx) installed +3. A basic understanding of [Blueprints](../blueprints/introduction.mdx) +4. A Blueprint created with the CLI as seen in [Step 1](#step-1-setting-up-the-project-structure) below + +## Blueprint Runner Structure + +A Blueprint Runner consists of: + +1. **Entry Point**: The runner is the primary component in a blueprint's `main.rs` +2. **[Jobs](/developers/blueprint-runner/jobs) Configuration**: Build the jobs that will be executed +3. **[Router](/developers/blueprint-runner/routers) Configuration**: Setup for directing job calls to the jobs themselves for handling +4. **[Producer](/developers/blueprint-runner/producers) Configuration**: Setup for the source of events (e.g. blockchain, external APIs) +5. **[Consumer](/developers/blueprint-runner/consumers) Configuration**: Setup for the handling of results from jobs +6. **[Background Service](/developers/blueprint-runner/background-services) Configuration**: Setup for supporting services (e.g. databases, servers, etc.) + +## Step-by-Step Guide + +### Step 1: Setting Up the Project Structure + +If you haven't already created a Blueprint project, you can use the Tangle CLI (if you haven't installed it yet, see [here](../cli/installation.mdx)): + +```bash +cargo tangle blueprint create --name +``` + +This creates a workspace with two main packages: + +- **Library Package**: Contains your job definitions and core logic +- **Binary Package**: Contains your Blueprint Runner implementation + +### Step 2: Defining Your Jobs + +Before building the runner, define the jobs that your Blueprint will execute. Jobs are defined in the library package: + + + +For more details on defining jobs, see the [Jobs documentation](/developers/blueprint-runner/jobs). + +### Step 3: Creating a Producer and a Consumer + +To build a Blueprint Runner, you need a producer to listen for events and a consumer to handle the results from jobs. + + + +### Step 4: Configuring the Router + +The [router](/developers/blueprint-runner/routers) directs job calls to the appropriate handlers. In the example below, we configure the router with a single route for our defined job and specify that it is on Tangle with the `TangleLayer`: + + + +This configuration: + +1. Creates a new router +2. Adds a route for the `square` job with ID `XSQUARE_JOB_ID` +3. Applies the `TangleLayer` to add metadata to job results +4. Adds a filter layer to only process jobs that match the service ID + +For more details on routers, see the [Routers documentation](/developers/blueprint-runner/routers). + +### Step 5: Defining a Background Service + +Some blueprints may require one or more services to run in the background. Any number of background services can be set to run for a Blueprint Runner. + + + +With a background service defined, it just needs to be added to the Blueprint Runner: + + + +### Step 6: Configuring a Producer with the Blueprint Runner's Builder + +[Producers](/developers/blueprint-runner/producers) listen for events and prepare them for processing. The following example uses a `TangleProducer` as seen in [Step 3](#step-3-creating-a-producer-and-a-consumer): + + + +This producer listens for finalized blocks on the Tangle network and converts them into job calls that can be processed by the router. + +For more details on producers, see the [Producers documentation](/developers/blueprint-runner/producers). + +### Step 7: Configuring a Consumer with the Blueprint Runner's Builder + +[Consumers](/developers/blueprint-runner/consumers) handle the results of processed jobs. In the example above, we set up a Tangle consumer as seen in [Step 3](#step-3-creating-a-producer-and-a-consumer): + + + +This consumer processes job results and can send transactions to the Tangle network based on those results. + +For more details on consumers, see the [Consumers documentation](/developers/blueprint-runner/consumers). + +### Step 8: Custom Shutdown Logic + +Implement customized shutdown logic to handle cleanup and resource release: + + + +The above example simply prints a message when the Blueprint Runner is shutting down. + +### Step 9: Running the Blueprint Runner + +Finally, we run the Blueprint Runner: + +```rust +// Build and run the Blueprint Runner +let result = BlueprintRunner::builder(tangle_config, env) + // ... configuration ... + .run() + .await; +``` + +The `run` method starts the Blueprint Runner and returns a result indicating whether it ran successfully or encountered an error. + +With this, the Blueprint Runner, the centerpoint of your Blueprint is ready to be used! + +## Next Steps + +After building your Blueprint Runner, you might want to explore: + +- [Advanced Router Features](/developers/blueprint-runner/routers#advanced-router-features) +- [Producer Patterns](/developers/blueprint-runner/producers#producer-patterns) +- [Consumer Patterns](/developers/blueprint-runner/consumers#consumer-patterns) + +## Conclusion + +Building a Blueprint Runner involves setting up various components that work together to execute your Tangle Blueprint. By following this guide and adhering to best practices, you can create a robust and efficient Blueprint Runner for your Actively Validated Service on the Tangle Network. diff --git a/pages/developers/blueprint-runner/consumers.mdx b/pages/developers/blueprint-runner/consumers.mdx new file mode 100644 index 0000000..3d8d025 --- /dev/null +++ b/pages/developers/blueprint-runner/consumers.mdx @@ -0,0 +1,99 @@ +--- +title: Consumers +--- + +import GithubFileReaderDisplay from '/components/GithubFileReaderDisplay'; + +# Consumers + +Consumers are a vital component of the [Blueprint Runner](/developers/blueprint-runner/introduction) architecture that handle the results of processed jobs. This document explains how consumers work, how to configure them, and best practices for implementation. + +## What are Consumers? + +In a Blueprint Runner, consumers are responsible for handling the results of job execution. They: + +1. Receive results from jobs via the [router](/developers/blueprint-runner/routers) +2. Process and transform these results as needed +3. Perform actions based on the results, such as: + - Sending transactions to the blockchain + - Updating local state + - Triggering other processes + - Storing data for later use + - Emitting events or notifications + +Consumers act as the output handlers of your Blueprint Runner, ensuring that job results lead to appropriate actions. + +## Consumer Configuration + +Consumers are typically configured in the `main.rs` file of your Blueprint binary, when defining the Blueprint Runner. The configuration involves: + +1. Creating a consumer +2. Defining how it processes job results +3. Connecting it to jobs via the [router](/developers/blueprint-runner/routers) + +### Basic Consumer Setup + +First, you define the consumer you want to use. For example, a `TangleConsumer` that listens for finalized blocks on Tangle. After which, you pass the consumer to the Blueprint Runner's builder. + +```rust +let env = BlueprintEnvironment::load()?; +let sr25519_signer = env.keystore().first_local::()?; +let sr25519_pair = env.keystore().get_secret::(&sr25519_signer)?; +let sr25519_signer = TanglePairSigner::new(sr25519_pair.0); + +let tangle_client = env.tangle_client().await?; +let tangle_producer = TangleProducer::finalized_blocks(tangle_client.rpc_client.clone()).await?; +let tangle_consumer = TangleConsumer::new(tangle_client.rpc_client.clone(), sr25519_signer); + +BlueprintRunner::builder(tangle_config, env) + .router(router) // Assuming your router is already defined + .producer(tangle_producer) + .consumer(tangle_consumer) + .run() + .await?; +``` + +## Types of Consumers + +Blueprint Runners can utilize various types of consumers depending on the requirements: + +### Tangle Consumer + +A Tangle Consumer is a consumer that handles transactions on the Tangle, submitting job results for a Blueprint. + + + +### EVM Consumer + +An EVM Consumer is a consumer that handles transactions on the EVM, submitting job results for a Blueprint. + + + +## Integration with Other Components + +Consumers work closely with other Blueprint Runner components: + +- **Routers**: [Routers](/developers/blueprint-runner/routers) pass job results to consumers for handling +- **Producers**: Results handled by consumers may generate new events for [producers](/developers/blueprint-runner/producers) to process + +## Next Steps + +Now that you understand consumers, learn about: + +- [Routers](/developers/blueprint-runner/routers) - How to direct job calls to appropriate handlers +- [Producers](/developers/blueprint-runner/producers) - How to capture and process events +- [Building a Blueprint Runner](/developers/blueprint-runner/building) - Step-by-step guide to building your own Blueprint Runner + +## Conclusion + +Consumers are essential components that translate job results into meaningful actions in your Blueprint Runner. By implementing robust and efficient consumers, you can ensure that your Blueprint operates reliably and effectively. diff --git a/pages/developers/blueprint-runner/introduction.mdx b/pages/developers/blueprint-runner/introduction.mdx new file mode 100644 index 0000000..9ae8c9c --- /dev/null +++ b/pages/developers/blueprint-runner/introduction.mdx @@ -0,0 +1,93 @@ +--- +title: Introduction to Blueprint Runners +--- + +import CardGrid from "../../../components/CardGrid.tsx" + +# Blueprint Runners + +Blueprint Runners are the core orchestration components that execute Tangle Blueprints. They manage the lifecycle of jobs, coordinate between different components, and ensure the reliable execution of your Actively Validated Service (AVS). + +## Getting Started + + + +## What is a Blueprint Runner? + +A Blueprint Runner is the runtime environment for your Tangle Blueprint. It: + +- Orchestrates job execution +- Manages communication between different components +- Handles event processing from the blockchain +- Manages state and persistence +- Ensures fault tolerance and reliability + +Blueprint Runners follow a modular architecture with four main components: [Routers](/developers/blueprint-runner/routers), [Producers](/developers/blueprint-runner/producers), [Consumers](/developers/blueprint-runner/consumers), and [Background Services](/developers/blueprint-runner/background-services). + +## Blueprint Runner Architecture + +The architecture of a Blueprint Runner consists of the following components: + +### Routers + +[Routers](/developers/blueprint-runner/routers) direct job calls to the appropriate job handlers based on job IDs. When a job is called, the router identifies the correct handler and passes the job parameters to it. + +### Producers + +[Producers](/developers/blueprint-runner/producers) listen for events (such as on-chain events from Tangle Network) and prepare them for processing. They convert raw event data into a format that can be processed by your job handlers. + +### Consumers + +[Consumers](/developers/blueprint-runner/consumers) handle the results of processed jobs. They can perform actions such as sending transactions, updating state, or triggering other processes based on job results. + +### Background Services + +[Background Services](/developers/blueprint-runner/background-services) are optional components that run continuously in the background. They can perform tasks such as monitoring, data collection, or periodic operations that are required for your jobs. + +## Blueprint Runner Lifecycle + +The Blueprint Runner follows a well-defined lifecycle to ensure reliable execution of your AVS: + +1. **Initialization**: The Blueprint Runner loads configuration, sets up components, and establishes connections. +2. **Event Processing**: [Producers](/developers/blueprint-runner/producers) listen for events and convert them into job inputs. +3. **Job Routing**: The [router](/developers/blueprint-runner/routers) directs job inputs to the appropriate job handlers. +4. **Job Execution**: Job handlers process the inputs and produce results. +5. **Result Handling**: [Consumers](/developers/blueprint-runner/consumers) process job results and perform necessary actions. +6. **Continuous Operation**: [Background services](/developers/blueprint-runner/background-services) run continuously to support the Blueprint Runner. + +## Next Steps + +Ready to build your own Blueprint Runner? Check out our [step-by-step guide](/developers/blueprint-runner/building) to get started. diff --git a/pages/developers/blueprint-runner/jobs.mdx b/pages/developers/blueprint-runner/jobs.mdx new file mode 100644 index 0000000..eb3df71 --- /dev/null +++ b/pages/developers/blueprint-runner/jobs.mdx @@ -0,0 +1,104 @@ +--- +title: Jobs +--- + +import GithubFileReaderDisplay from '/components/GithubFileReaderDisplay'; + +# Jobs + +Jobs are the core building blocks of a [Blueprint Runner](/developers/blueprint-runner/introduction). They define the computational tasks that your Blueprint will execute in response to events. This document explains how jobs work, how to define them, and how to integrate them with other components of your Blueprint. + +## What are Jobs? + +In a Blueprint, jobs are functions that: + +1. Receive inputs from [producers](/developers/blueprint-runner/producers) +2. Perform specific computational tasks +3. Return results that can be processed by [consumers](/developers/blueprint-runner/consumers) + +Jobs are the heart of your Blueprint's functionality, encapsulating the business logic that processes events and produces meaningful results. + +## Job Definition + +Jobs in a Blueprint are defined in the library package of your project. A job definition consists of: + +1. A unique job ID that identifies the job +2. A function that implements the job's logic +3. Input parameters that the job accepts +4. Return values that the job produces + +### Basic Job Structure + +Here's an example of a simple job definition from the Incredible Squaring example: + + + +In this example: + +- `XSQUARE_JOB_ID` is a constant that uniquely identifies the job +- `square` is the function that implements the job's logic +- The job takes a single input parameter `x` of type `i32` +- The job returns a result of type `i32`, which is the square of the input + +## Job Context + +Jobs can access context information provided by the Blueprint Runner. This context can include: + +- Configuration settings +- Connections to external systems +- State information +- Utility functions + +Context is typically passed to jobs through the router configuration: + +```rust +let router = Router::builder() + .route(MY_JOB_ID, my_job) + .with_context(my_context); +``` + +## Job Registration + +Jobs need to be registered to a route with the [router](/developers/blueprint-runner/routers) to be accessible. This is done when defining a Blueprint Runner: + + + +## Job Execution Flow + +The execution flow of a job in a Blueprint Runner follows these steps: + +1. A [producer](/developers/blueprint-runner/producers) generates a job call with specific parameters +2. The [router](/developers/blueprint-runner/routers) directs the job call to the appropriate job handler +3. The job executes its logic and produces a result +4. The result is passed to [consumers](/developers/blueprint-runner/consumers) for further processing + +## Integration with Other Components + +Jobs work closely with other Blueprint Runner components: + +- **Routers**: [Routers](/developers/blueprint-runner/routers) direct job calls to the appropriate job handlers +- **Producers**: [Producers](/developers/blueprint-runner/producers) generate job calls with specific parameters +- **Consumers**: [Consumers](/developers/blueprint-runner/consumers) process the results of job execution + +## Next Steps + +Now that you understand jobs, it might be helpful to take a look at: + +- [Routers](/developers/blueprint-runner/routers) - How to direct job calls to appropriate handlers +- [Producers](/developers/blueprint-runner/producers) - How to capture and process events +- [Consumers](/developers/blueprint-runner/consumers) - How to handle job results +- [Building a Blueprint Runner](/developers/blueprint-runner/building) - Step-by-step guide to building your own Blueprint Runner + +## Conclusion + +Jobs are the core building blocks of your Blueprint, encapsulating the business logic that processes events and produces meaningful results. By implementing well-designed jobs, you can create powerful and flexible Blueprints that can handle a wide range of use cases. diff --git a/pages/developers/blueprint-runner/producers.mdx b/pages/developers/blueprint-runner/producers.mdx new file mode 100644 index 0000000..8bdf9bc --- /dev/null +++ b/pages/developers/blueprint-runner/producers.mdx @@ -0,0 +1,94 @@ +--- +title: Producers +--- + +import GithubFileReaderDisplay from '/components/GithubFileReaderDisplay'; + +# Producers + +Producers are a key component of the [Blueprint Runner](/developers/blueprint-runner/introduction) architecture that capture events and prepare them for processing. This document explains how producers work, how to configure them, and how to implement them. + +## What are Producers? + +In a Blueprint Runner, producers are responsible for: + +1. Listening for events from a given source (e.g., blockchain events, polling calls, etc.) +2. Preparing events to be passed to a job for processing, with the router + +Producers act as the input handlers of your Blueprint Runner, ensuring that external events are properly captured and processed. + +## Producer Configuration + +Producers are typically configured in the `main.rs` file of your Blueprint binary, when defining the Blueprint Runner. It is a `Stream` that outputs a JobCall, which is then passed to the router and routed to the appropriate job. A Producer can be made to generate JobCalls from anything, but we have some built-in producers that can be used out of the box. + +### Basic Producer Setup + +First, you define the producer you want to use. For example, a `TangleProducer` that listens for finalized blocks on Tangle. After which, you pass the producer to the Blueprint Runner's builder. + +```rust +let env = BlueprintEnvironment::load()?; +let tangle_client = env.tangle_client().await?; +let tangle_producer = TangleProducer::finalized_blocks(tangle_client.rpc_client.clone()).await?; + +BlueprintRunner::builder(tangle_config, env) + .router(router) // Assuming your router is already defined + .producer(tangle_producer) + .run() + .await?; +``` + +## Types of Producers + +Blueprint Runners can utilize various types of producers depending on the event sources: + +### Blockchain Producers + +These producers listen for events from a blockchain, such as smart contract events or finalized blocks. + +There are currently two built-in blockchain producers: + +#### Tangle Producer + + + +#### EVM Polling Producer + + + +### Cron Jobs + + + +## Integration with Other Components + +Producers work closely with other Blueprint Runner components: + +- **Routers**: Producers submit JobCalls to their [router](/developers/blueprint-runner/routers), where they are routed to the appropriate job +- **Consumers**: JobCalls processed by producers ultimately lead to results handled by [consumers](/developers/blueprint-runner/consumers) + +## Next Steps + +Now that you understand producers, learn about: + +- [Routers](/developers/blueprint-runner/routers) - How to direct job calls to appropriate handlers +- [Consumers](/developers/blueprint-runner/consumers) - How to handle job results +- [Building a Blueprint Runner](/developers/blueprint-runner/building) - Step-by-step guide to building your own Blueprint Runner + +## Conclusion + +Producers are essential components that capture and prepare events for processing in your Blueprint Runner. By implementing robust and efficient producers, you can ensure that your Blueprint reliably processes desired events. diff --git a/pages/developers/blueprint-runner/routers.mdx b/pages/developers/blueprint-runner/routers.mdx new file mode 100644 index 0000000..ca7f8d0 --- /dev/null +++ b/pages/developers/blueprint-runner/routers.mdx @@ -0,0 +1,78 @@ +--- +title: Routers +--- + +import GithubFileReaderDisplay from '/components/GithubFileReaderDisplay'; + +# Routers + +Routers are a critical component of the [Blueprint Runner](/developers/blueprint-runner/introduction) architecture. They are responsible for directing job calls to the appropriate job handlers based on job IDs. This document explains how routers work, how to configure them, and best practices for implementation. + +## What are Routers? + +In a Blueprint Runner, a router acts as a traffic director for job execution. When a job is called, the router: + +1. Identifies the correct handler for the job based on the job ID +2. Validates the job parameters +3. Passes the parameters to the job handler +4. Returns the result to the consumer + +Routers ensure that jobs are executed by the appropriate handlers, making them essential for the proper functioning of your Blueprint Runner. + +## Router Configuration + +Routers are configured when building the Blueprint Runner in the `main.rs` file of your Blueprint's binary. The configuration involves: + +1. Creating a new router +2. Defining routes for each job you have, mapping a job ID to each job in it's route +3. Setting a context for the router, which will contain any resources needed by the jobs + +### Basic Router Setup + +A simple router setup might look like this, assuming you have already created a job and context: + +```rust +use blueprint_sdk::runner::BlueprintRunner; +use blueprint_sdk::Router; + +let router = Router::builder() + .route(MY_JOB_ID, my_job) + .with_context(my_context); +``` + +Below is a real example from our Incredible Squaring Blueprint Example: + + + +## Layers + +Layers are used to filter job calls based on certain criteria. There are two places layers can be used: + +1. A specific Route: + - A job can be given a layer. This can be seen in the above code example, where the job is in the `TangleLayer`. This allows the consumer, which operates in that layer, to see the results from that job. This simplifies your Blueprint when you have many jobs, routes, and consumers. +2. A whole Router: + - A layer can be used to filter job calls based on some criteria. This can also be seen in the above code example, where the router is given a filter for the service ID. This allows the router to only process jobs with a matching service ID. + +## Integration with Other Components + +Routers work closely with other Blueprint Runner components: + +- **Producers**: [Producers](/developers/blueprint-runner/producers) pass job calls to the router for processing +- **Consumers**: The router passes job results to [Consumers](/developers/blueprint-runner/consumers) for handling + +## Next Steps + +Now that you understand routers, check out: + +- [Producers](/developers/blueprint-runner/producers) - How to capture and process events +- [Consumers](/developers/blueprint-runner/consumers) - How to handle job results +- [Building a Blueprint Runner](/developers/blueprint-runner/building) - Step-by-step guide to building your own Blueprint Runner + +## Conclusion + +Routers are a fundamental component of Blueprint Runners, enabling efficient job execution and management. By properly configuring and utilizing routers, you can build robust and performant Blueprints and AVSs. diff --git a/pages/developers/blueprint-sdk.mdx b/pages/developers/blueprint-sdk.mdx index 40a4497..90e9336 100644 --- a/pages/developers/blueprint-sdk.mdx +++ b/pages/developers/blueprint-sdk.mdx @@ -23,7 +23,7 @@ import TableOfContentCards from "../../components/TableOfContentCards.tsx" }, { title: "CLI Tools", - href: "/developers/cli", + href: "/developers/cli/quickstart", subItems: [ { title: "Installation", @@ -36,9 +36,19 @@ import TableOfContentCards from "../../components/TableOfContentCards.tsx" description: "Get started with basic CLI commands" }, { - title: "Reference", - href: "/developers/cli/reference", - description: "Complete CLI command reference" + title: "Tangle Blueprints", + href: "/developers/cli/tangle", + description: "Build and deploy Tangle Blueprints" + }, + { + title: "Eigenlayer AVS Blueprints", + href: "/developers/cli/eigenlayer", + description: "Build and deploy Eigenlayer AVS Blueprints" + }, + { + title: "Key Management", + href: "/developers/cli/keys", + description: "Create and manage keys and keystores for Blueprints" } ] }, diff --git a/pages/developers/eigenlayer-avs/bls-example.mdx b/pages/developers/eigenlayer-avs/bls-example.mdx index 26f1e7a..e7f2e98 100644 --- a/pages/developers/eigenlayer-avs/bls-example.mdx +++ b/pages/developers/eigenlayer-avs/bls-example.mdx @@ -39,19 +39,19 @@ When you deploy the TangleTaskManager, you are also given the option to initiali You will be prompted for each contract's constructor arguments (if it has any). You can find the addresses of the contracts you need in your project's settings.env file. Below is a complete list of addresses you will need. Some are zero addresses because they aren't actually used. -### Addresses for deployment - -| Address | Value | -| -------------------- | -------------------------------------------- | -| Registry Coordinator | 0xc3e53f4d16ae77db1c982e75a937b9f60fe63690 | -| Pauser Registry | Obtained from beginning of Deployment output | -| Initial Owner | 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 | -| Aggregator | 0xa0Ee7A142d267C1f36714E4a8F75612F20a79720 | -| Generator | 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 | -| AVS Directory | 0x0000000000000000000000000000000000000000 | -| Rewards Coordinator | 0x0000000000000000000000000000000000000000 | -| Stake Registry | 0x5fc8d32690cc91d4c39d9d3abcbd16989f875707 | -| Tangle Task Manager | Obtained in Deployment output | +### Default Addresses for demo deployment + +| Address | Value | +| -------------------- | ------------------------------------------ | +| Registry Coordinator | Obtained from Deployment output | +| Pauser Registry | Obtained from Deployment output | +| Initial Owner | 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 | +| Aggregator | 0xa0Ee7A142d267C1f36714E4a8F75612F20a79720 | +| Generator | 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 | +| AVS Directory | 0x5fc8d32690cc91d4c39d9d3abcbd16989f875707 | +| Rewards Coordinator | 0xb7f8bc63bbcad18155201308c8f3540b07f84f5e | +| Stake Registry | 0x4c5859f0f772848b2d91f1d83e2fe57935348029 | +| Tangle Task Manager | Obtained from Deployment output | Once all contracts have been deployed, you will notice that it continues running to keep the testnet alive. diff --git a/pages/developers/eigenlayer-avs/bls-template.mdx b/pages/developers/eigenlayer-avs/bls-template.mdx index afd884a..3303ac6 100644 --- a/pages/developers/eigenlayer-avs/bls-template.mdx +++ b/pages/developers/eigenlayer-avs/bls-template.mdx @@ -68,17 +68,17 @@ cargo tangle blueprint deploy eigenlayer \ If you're using the template as is, you can find the addresses of the contracts you need in your project's settings.env file. Others are below. -| Address | Value | -| -------------------- | -------------------------------------------- | -| Registry Coordinator | 0xc3e53f4d16ae77db1c982e75a937b9f60fe63690 | -| Pauser Registry | Obtained from beginning of Deployment output | -| Initial Owner | 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 | -| Aggregator | 0xa0Ee7A142d267C1f36714E4a8F75612F20a79720 | -| Generator | 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 | -| AVS Directory | 0x0000000000000000000000000000000000000000 | -| Rewards Coordinator | 0x0000000000000000000000000000000000000000 | -| Stake Registry | 0x5fc8d32690cc91d4c39d9d3abcbd16989f875707 | -| Tangle Task Manager | Obtained in Deployment output | +| Address | Value | +| -------------------- | ------------------------------------------ | +| Registry Coordinator | Obtained from Deployment output | +| Pauser Registry | Obtained from Deployment output | +| Initial Owner | 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 | +| Aggregator | 0xa0Ee7A142d267C1f36714E4a8F75612F20a79720 | +| Generator | 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 | +| AVS Directory | 0x5fc8d32690cc91d4c39d9d3abcbd16989f875707 | +| Rewards Coordinator | 0xb7f8bc63bbcad18155201308c8f3540b07f84f5e | +| Stake Registry | 0x4c5859f0f772848b2d91f1d83e2fe57935348029 | +| Tangle Task Manager | Obtained from Deployment output | Once all contracts have been deployed, you will notice that it continues running to keep the testnet alive. @@ -153,8 +153,8 @@ cargo test The template provides a foundation that you can build upon: - The contracts are named TangleServiceManager.sol, TangleTaskManager.sol, and ITangleTaskManager.sol by default. Use find-and-replace to rename as needed. -- For event listener examples, see [event listeners documentation](/developers/blueprint-event-listeners/introduction). -- For job implementation details, consult the [jobs documentation](/developers/blueprint-macros/jobs). +- For information on runners, see [blueprint runner documentation](/developers/tangle-avs#blueprint-runner-architecture). +- For an example job implementation, consult the [jobs documentation](/developers/tangle-avs#libsrclibrs). ## Development Keys diff --git a/pages/developers/eigenlayer-avs/ecdsa-template.mdx b/pages/developers/eigenlayer-avs/ecdsa-template.mdx index 0a7fb3d..570c2a4 100644 --- a/pages/developers/eigenlayer-avs/ecdsa-template.mdx +++ b/pages/developers/eigenlayer-avs/ecdsa-template.mdx @@ -66,17 +66,17 @@ cargo tangle blueprint deploy eigenlayer \ If you're using the template as is, you can find the addresses of the contracts you need in your project's settings.env file. Others are below. -| Address | Value | -| -------------------- | -------------------------------------------- | -| Registry Coordinator | 0xc3e53f4d16ae77db1c982e75a937b9f60fe63690 | -| Pauser Registry | Obtained from beginning of Deployment output | -| Initial Owner | 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 | -| Aggregator | 0xa0Ee7A142d267C1f36714E4a8F75612F20a79720 | -| Generator | 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 | -| AVS Directory | 0x0000000000000000000000000000000000000000 | -| Rewards Coordinator | 0x0000000000000000000000000000000000000000 | -| Stake Registry | 0x5fc8d32690cc91d4c39d9d3abcbd16989f875707 | -| Tangle Task Manager | Obtained in Deployment output | +| Address | Value | +| -------------------- | ------------------------------------------ | +| Registry Coordinator | Obtained from Deployment output | +| Pauser Registry | Obtained from Deployment output | +| Initial Owner | 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 | +| Aggregator | 0xa0Ee7A142d267C1f36714E4a8F75612F20a79720 | +| Generator | 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 | +| AVS Directory | 0x5fc8d32690cc91d4c39d9d3abcbd16989f875707 | +| Rewards Coordinator | 0xb7f8bc63bbcad18155201308c8f3540b07f84f5e | +| Stake Registry | Obtained from Deployment output | +| Tangle Task Manager | Obtained from Deployment output | Once all contracts have been deployed, you will notice that it continues running to keep the testnet alive. @@ -151,8 +151,8 @@ cargo test The template provides a foundation that you can build upon: - The default contract is named TangleServiceManager.sol (with related test files TestTangleServiceManager.sol and TangleServiceManager.t.sol). Use find-and-replace to rename as needed. -- For event listener examples, see [event listeners documentation](/developers/blueprint-event-listeners/introduction). -- For job implementation details, consult the [jobs documentation](/developers/blueprint-macros/jobs). +- For an example of a blueprint runner, see [blueprint runner documentation](/developers/tangle-avs#blueprint-runner-architecture). +- For a job implementation example, consult the [job documentation](/developers/tangle-avs#libsrclibrs). ## Development Keys diff --git a/pages/developers/eigenlayer-avs/incredible-squaring-avs.mdx b/pages/developers/eigenlayer-avs/incredible-squaring-avs.mdx index 757464a..064544c 100644 --- a/pages/developers/eigenlayer-avs/incredible-squaring-avs.mdx +++ b/pages/developers/eigenlayer-avs/incredible-squaring-avs.mdx @@ -8,103 +8,114 @@ import GithubFileReaderDisplay from "/components/GithubFileReaderDisplay"; ## Introduction -This will guide you through setting up and using EVM event listeners for EigenLayer AVSes, using examples from the +This guide will walk you through building an EigenLayer AVS (Actively Validated Service) using Tangle Blueprints, using examples from the [Incredible Squaring blueprint implementation](https://github.com/tangle-network/blueprint/tree/main/examples/incredible-squaring-eigenlayer). -EVM event listeners are crucial for interacting with smart contracts on Ethereum-compatible networks. -In the context of EigenLayer and the blueprint macro system, these listeners allow your Gadget to respond to specific -events emitted by EigenLayer contracts. +The Incredible Squaring AVS is a simple example that demonstrates how to build an AVS that squares numbers. While the computation is trivial, the example showcases the key components of an EigenLayer AVS built with Tangle Blueprints. -## Setting Up EVM Event Listeners +## Blueprint Structure -### 1. Contract Definition +The Incredible Squaring AVS blueprint follows the basic library and binary structure: -First, define the contract interface using the `sol!` and `load_abi!` macros. This generates Rust bindings for your smart contract. +1. **Library**: Contains job definitions and core logic +2. **Binary**: Contains the Blueprint Runner implementation -{/* TODO: Add URL */} +## Job Definitions + +Jobs are the core computational units in your Blueprint. For the Incredible Squaring AVS, we define jobs to handle various tasks: -### 2. Job Definition with Event Handler - -Use the [`#[job]`](/developers/blueprint-macros/jobs) macro to define a function that will handle specific events. Include the `event_listener` attribute to specify the event details: - -{/* TODO: Add URL */} +This job initializes a new task in the Incredible Squaring AVS. It takes parameters from an EVM event and processes them. -### 3. Event Converter Preprocessor Function +This job computes the square of a number in the Incredible Squaring AVS and sends the result as a signed response to an Aggregator. -Implement a preprocessor function to convert the event data into the format expected by your job function: +## Working with EVM Smart Contracts -{/* TODO: Add URL */} +To interact with EVM smart contracts, the blueprint uses the `alloy` crate -## Implementing the Event Listener +## Blueprint Runner Architecture -### 1. Set Up the Provider +The Blueprint Runner is the core component that orchestrates the execution of your Blueprint. For the Incredible Squaring AVS, it consists of several key components: -Create an HTTP provider to connect to the Ethereum network w/ a wallet enabled for transacting: +### 1. Setting Up the Provider -{/* TODO: Add URL */} +First, create an HTTP provider to connect to the Ethereum network with a wallet enabled for transacting: -### 2. Create the Contract Instances and Event Listeners - -Instantiate the contract using the generated bindings: +### 2. Creating Contexts -{/* TODO: Add URL */} +Next, create the contexts that will be used by your jobs: -### 3. Set up the BlueprintRunner +### 3. Setting Up Producers -Use the `BlueprintRunner` to execute the jobs and background services: +Producers listen for events and prepare them for processing. In the Incredible Squaring AVS, we set up producers to listen for EVM events: -{/* TODO: Add URL */} + + +### 4. Configuring the Blueprint Runner + +Finally, set up the Blueprint Runner with the router, producers, consumers, and background services: +The Blueprint Runner: + +- Uses a router to direct job calls to the appropriate handlers +- Sets up a producer that listen for events and prepare them for processing +- Our job automatically handles signed task responses, so we don't use a consumer +- Configures Aggregator as background services + ## Testing the Incredible Squaring AVS ### 1. Prerequisites Before you begin, ensure you have the following installed: - Anvil - Docker +- Anvil +- Docker (DockerDesktop) ### 2. Installation @@ -112,7 +123,7 @@ Clone this repository: ```shell git clone https://github.com/tangle-network/blueprint.git -cd gadget +cd blueprint ``` Install Anvil: @@ -122,21 +133,21 @@ curl -L https://foundry.paradigm.xyz | bash foundryup ``` -Running the AVS on a Testnet +### 3. Running the AVS on a Testnet - We have a test for running this AVS Blueprint on a local Anvil Testnet. You can run the test with the following: +We have a test for running this AVS Blueprint on a local Anvil Testnet. You can run the test with the following: ```shell -RUST_LOG=gadget=trace cargo test --package incredible-squaring-blueprint-eigenlayer test_eigenlayer_incredible_squaring_blueprint -- --nocapture +cargo test --package incredible-squaring-blueprint-eigenlayer test_eigenlayer_incredible_squaring_blueprint ``` ## Best Practices and Considerations -1. **Error Handling**: Implement robust error handling in your event listener functions to manage potential failures gracefully. +1. **Error Handling**: Implement robust error handling in your job functions to manage potential failures gracefully. 2. **Asynchronous Operations**: Use `async/await` for operations that may take time, such as network requests or complex computations. -3. **Event Filtering**: Consider implementing additional filtering logic in your event converter function if you need to process only specific events based on certain criteria. -4. **State Management**: If your Gadget needs to maintain state between events, consider implementing a state management system. -5. **Testing**: Implement unit tests for your event handling logic, including the event converter function. -6. **Logging**: Use appropriate logging to track the event handling process and aid in debugging. -7. **Gas Considerations**: Be aware of the gas costs associated with your on-chain interactions, especially when responding to events with transactions. -8. **Scalability**: Design your event handling system to scale with the number of events you expect to process. +3. **State Management**: If your AVS needs to maintain state between job executions, consider implementing a state management system. +4. **Testing**: Implement unit tests for your job logic and integration tests for the complete AVS. +5. **Logging**: Use appropriate logging to track the job execution process and aid in debugging. +6. **Gas Considerations**: Be aware of the gas costs associated with your on-chain interactions, especially when responding to events with transactions. +7. **Scalability**: Design your AVS to scale with the number of tasks you expect to process. +8. **Security**: Ensure your AVS follows security best practices, especially when handling cryptographic operations. diff --git a/pages/developers/tangle-avs.mdx b/pages/developers/tangle-avs.mdx index d667344..08a7797 100644 --- a/pages/developers/tangle-avs.mdx +++ b/pages/developers/tangle-avs.mdx @@ -21,51 +21,68 @@ Before you begin, ensure you have the following installed: See the [CLI Quickstart](./cli/quickstart.mdx) for instructions on creating a [blueprint](./blueprints/introduction.mdx). -### Key Files - -#### src/lib.rs - -This file contains the core logic of your Blueprint, including job definitions, report structures, and event listeners. Here's an example of a simple "Hello World" job: +### Blueprint Workspace Structure -1. **Jobs**: Define the main computational tasks of your Blueprint. For more details on creating jobs, see our [Blueprint Job Documentation](/developers/blueprint-macros/jobs). +Tangle Blueprints are structured as Rust workspaces with multiple packages: -2. **Reports**: Define offchain reporting logic for the custom slashing functionality of your Blueprint. Learn more about reports in our [Blueprint Report Documentation](/developers/blueprint-macros/reports). +1. **Library Package**: Contains the core logic of your Blueprint, including job definitions. +2. **Binary Package**: Contains the entry point for your Blueprint runner. -3. **Event Listeners**: Set up listeners to react to on-chain events, offchain events, cron-job like listeners, and even custom event triggers. For a deep dive into event listeners, check out our [Event Listener Documentation](/developers/blueprint-event-listeners/introduction). +### Key Files -Here's a basic example incorporating these elements: +#### lib/src/lib.rs -{/* TODO: Add URL */} +This file contains the core logic of your Blueprint, including job definitions. Jobs are the main computational tasks that your Blueprint will execute. Here's an example of a simple "Hello World" job: This job takes an optional `who` parameter and returns a greeting. -#### src/main.rs +For more details on creating jobs, see our [Blueprint Job Documentation](/developers/blueprint-macros/jobs). + +#### bin/src/main.rs -This file serves as the entry point for your Actively Validated Service (AVS) node. It sets up the runtime environment, initializes the necessary components, and starts the event watcher. Here's a breakdown of its key responsibilities: +This file serves as the entry point for your Actively Validated Service (AVS) node. It sets up the runtime environment, initializes the necessary components, and starts the Blueprint Runner. Here's a breakdown of its key responsibilities: 1. **Environment Setup**: It loads the configuration, initializes the logger, and sets up error handling. 2. **Client Initialization**: It creates a connection to the Tangle Network using the provided RPC endpoint. -3. **Registration**: It checks if the node should run registration (implementation pending). -4. **Event Handler Creation**: It instantiates the event handler for the `say_hello` job. -5. **Event Watcher**: It starts the Substrate event watcher, which listens for relevant events on the Tangle Network. - -{/* TODO: Add URL */} +3. **Router Configuration**: It sets up the router that directs job calls to the appropriate handlers. +4. **Producer Setup**: It configures producers that listen for events and prepare them for processing. +5. **Consumer Setup**: It configures consumers that handle processed results. +6. **Background Services**: It initializes optional background services required for jobs. +7. **Blueprint Runner**: It starts the Blueprint Runner, which orchestrates all components. -This sets up the AVS node, initializes the environment, and starts the event watcher. +## Blueprint Runner Architecture + +The Blueprint Runner is the core component that orchestrates the execution of your Blueprint. It consists of several key components: + +### Router + +The router is responsible for directing job calls to the appropriate job handlers based on job IDs. When a job is called, the router identifies the correct handler and passes the job parameters to it. + +### Producers + +Producers listen for events (such as on-chain events from Tangle Network) and prepare them for processing. They convert raw event data into a format that can be processed by your job handlers. + +### Consumers + +Consumers handle the results of processed jobs. They can perform actions such as sending transactions, updating state, or triggering other processes based on job results. + +### Background Services + +Background services are optional components that run continuously in the background. They can perform tasks such as monitoring, data collection, or periodic operations that are required for your jobs. ## Building Your Project @@ -85,27 +102,21 @@ See [deploying your blueprint](./cli/quickstart.mdx#deploying-your-blueprint). Congratulations! You've created, built, and deployed your first Tangle Blueprint. Here are some suggestions for what to do next: -1. Explore more complex job implementations in your `lib.rs` file. Learn more about [Jobs and the Job Macro system](/developers/blueprint-macros/jobs). +1. Explore more complex job implementations in your library package. Learn more about [Jobs](/developers/blueprint-macros/jobs). {/* TODO: Use new jobs page */} -2. Implement reporting mechanisms using the [Reports Macro](/developers/blueprint-macros/reports) to ensure the integrity of your AVS. +2. Learn about [Context and Context Extensions](/developers/blueprint-macros/context) to manage dependencies and state in your Blueprint. -3. Dive deeper into [Event Listeners](/developers/blueprint-event-listeners/introduction) to understand how to trigger your jobs and reports based on various events. +3. Customize your Blueprint Runner with additional producers, consumers, and background services to handle more complex scenarios. -4. Learn about [Context and Context Extensions](/developers/blueprint-macros/context) to manage dependencies and state in your Blueprint. +4. If you're interested in building for EigenLayer, check out our guide on [Building an EigenLayer AVS](/developers/eigenlayer-avs). -5. If you're interested in building for EigenLayer, check out our guide on [Building an EigenLayer AVS](/developers/eigenlayer-avs). +5. Implement tests for your Blueprint using `tokio::test`. Learn more about [Testing Blueprints](/developers/blueprint-macros/testing). -6. Implement tests for your Blueprint using `tokio::test`. Learn more about [Testing Blueprints](/developers/blueprint-macros/testing). +6. Explore the Tangle network's features and how they interact with your Blueprint. Understand [EVM and Native Addresses](/developers/technicals/addresses) and [EVM to Substrate transfers](/developers/technicals/evm-substrate-transfers). -7. Explore the Tangle network's features and how they interact with your Blueprint. Understand [EVM and Native Addresses](/developers/technicals/addresses) and [EVM to Substrate transfers](/developers/technicals/evm-substrate-transfers). +7. Familiarize yourself with [EVM Precompiles](/developers/technicals/precompiles) available on Tangle Network. -8. Familiarize yourself with [EVM Precompiles](/developers/technicals/precompiles) available on Tangle Network. - -9. Learn about [Deploying Contracts with Hardhat](/developers/technicals/deploy-using-hardhat) for more advanced contract deployment scenarios. - -For more advanced topics and in-depth information, check out our other documentation pages and the [Rust async book](https://rust-lang.github.io/async-book/). - -If you encounter any issues or have questions, please don't hesitate to open an issue on our [GitHub repository](https://github.com/tangle-network/blueprint-template/issues). We're here to help you succeed in building with Tangle Blueprints! +8. Learn about about advanced options when [Deploying Blueprints](./cli/tangle.mdx#deploying-a-blueprint). For more advanced topics and in-depth information, check out our other documentation pages and the [Rust async book](https://rust-lang.github.io/async-book/). diff --git a/pages/developers/troubleshooting.mdx b/pages/developers/troubleshooting.mdx index c02deb1..059edf8 100644 --- a/pages/developers/troubleshooting.mdx +++ b/pages/developers/troubleshooting.mdx @@ -27,16 +27,7 @@ Caused by: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` -1. Verify your `gadget` version and compare your `rust_toolchain.toml` against the [Blueprint Template](https://github.com/tangle-network/blueprint-template) repository. - - - -2. Verify that your blueprint's jobs and reports are implemented correctly. Occasionally, our SDK may have breaking changes to the error reporting. You will want to consider commenting out metadata generation and then rebuilding to check for errors in the blueprint. +Verify that your blueprint's jobs and reports are implemented correctly. Occasionally, our SDK may have breaking changes to the error reporting. You will want to consider commenting out metadata generation and then rebuilding to check for errors in the blueprint. {/* TODO: Add URL */}