feat: improve blueprint intro (#78)

pages/developers/blueprints.mdx

@@ -4,21 +4,37 @@ import ExpandableImage from "../../components/ExpandableImage.tsx"
 
 # Blueprints
 
-Blueprints are specifications for Actively Validated Services (AVS) on the Tangle Network. An AVS is an off-chain service that runs arbitrary computations for a user-specified period of time. A Blueprint is defined by:
+**Blueprints** are specifications for Actively Validated Services (AVS) or **Instances** on the Tangle Network. Developers build blueprints using our [Gadget SDK](https://github.com/tangle-network/gadget) and deploy them to the Tangle Network. Once deployed, users can create Instances of the Blueprint, which are run by Tangle Operators. The Tangle Network incentivizes operators to run these instances by rewarding them with TNT tokens. Developers incentivize operators to run instances by specifying fees and additional rewards in the Blueprint.
 
-- An off-chain program binary (known as a Blueprint Gadget)
+An Actively Validated Service or Blueprint Instance is an computational service that runs a specified period of time, potentially user-specified or on-demand or forever. Instances allow Blueprints to be reused multiple times, so that useful services can be leveraged by many customers. A key benefit of instancing Blueprints is that each instance can have different operators and diffierent restaked assets securing them.
+
+A Tangle Blueprint is defined by:
+
+- An program binary.
 - A set of smart contracts that provide programmability over the service's output verification and handling of malicious failures
 
+Tangle Blueprints specify their target environment for program execution. The Blueprint's binary can run natively on the operator's machine, in a virtual machine, or in a containerized environment. We are constantly working to provide the right environments for developers to build Blueprints so that operators are satisfied executing Blueprint Instances. Our Gadget SDK supports building AVS and Blueprint Instances directly on Eigenlayer without the same instancing as exists on Tangle, allowing developers nonetheless to leverage the features of our SDK to build and test their services on Eigenlayer. Future integrations with other restaking infrastructures are planned.
+
 <BlueprintIntroCards />
 
+## Blueprint Manager
+
+On Tangle, Blueprints have an offchain and an onchain lifecycle. The offchain component is managed by what we call the **Blueprint Manager**. The **Blueprint Manager** can be considered **_Tangle's Operator Node_**. We even plan to run the Blueprint Manager as an AVS on other restaking infrastructures in order to aggregate operators and assets around Tangle Blueprints.
+
+This onchain and offchain logic functions as follows:
+
+1. Operators must register for Blueprints onchain. This indicates an operators willingness to accept requests for Blueprint Instances of that type.
+2. Operators upon registering for Blueprints onchain, download the Blueprint's binary and metadata from the Tangle Network. This is handled by the Blueprint Manager, which listens for new registrations.
+3. Operators upon accepting Blueprint Instance requests, execute the Blueprint's binary. This is where the target environment of the Blueprint is important. The Blueprint Manager is responsible for executing the Blueprint's binary in the correct environment be it natively or in Docker or an alternative VM.
+
 ### Blueprint and Service Instance Lifecycle
 
 <ExpandableImage src="/images/ServiceInstanceFlow.png" alt="Service Instance Flow" />
 
 Blueprints interact with the Tangle Network in several key ways:
 
 1. Blueprints are deployed to Tangle, with their metadata and smart contracts stored and deployed on-chain.
-2. Blueprints are instantiated, triggering the creation of an Instance, which represents a single AVS. The Instance runs for a modifiable period of time.
+2. Blueprints are instantiated, triggering the creation of an Instance, which represents a single AVS. The Instance runs for some period of time.
 3. Blueprints are destroyed once they reach their time-to-live (TTL) or run out of funds to incentivize operators to run their service.
 
 Blueprints provide a useful abstraction, allowing developers to create reusable service infrastructures as if they were smart contracts. This enables developers to monetize their work and align long-term incentives with the success of their creations, benefiting proportionally to their Blueprint's usage.
@@ -31,16 +47,17 @@ The Blueprint object is the core restaking object in Tangle, implemented primari
 
 Developers interact with Tangle Blueprints by deploying them to the blockchain. A Blueprint specification contains metadata and smart contracts, currently targeting the EVM. The smart contracts are deployed to the Tangle EVM, while the metadata is stored in Tangle's runtime.
 
-The Blueprint includes two key smart contracts:
-
-1. **Registration Contract**: Specifies how Operators register for the Blueprint, allowing the developer to add additional fees, access control, KYC, and any other EVM-deployable functionality to the registration process.
-2. **Request Contract**: Defines how consumers of Blueprints initiate Service Instances, providing the same customizability as the EVM for the initialization process of Service Instances.
+The Blueprint includes one main smart contract responsible with all aspects of customizing a Blueprint's behavior and features. Developers have the flexibility to extend this contract, create child contracts, and anything that adheres to the function signatures expected by the runtime when executing logic. The Blueprint smart contract handles:
 
-The metadata stores and controls the off-chain service of the Blueprint, known as the Blueprint Gadget, which represents the location of the program binary (open-source or potentially closed-source) that executes the off-chain service. The metadata can be updated as the Blueprint evolves.
+1. **Registration**: Specifies how Operators register for the Blueprint, allowing the developer to add additional fees, access control, KYC, and any other EVM-deployable functionality to the registration process.
+2. **Request**: Defines how consumers of Blueprints initiate Service Instances, providing the same customizability as the EVM for the initialization process of Service Instances.
+3. **On Job Hooks**: Allows developers to specify custom logic to be executed when a job is created.
+4. **On Job Result Hooks**: Allows developers to specify custom logic to be executed when a job is completed, such as verifying a job's output.
+5. **Custom slashing conditions**: Allows developers to specify custom slashing conditions for Operators, such as failing to provide a service or providing a malicious service. These would be callable by anyone or priveledged callers but is entirely up to the developer to design.
 
 Blueprint upgrades are handled differently than runtime upgrades and should eventually be supported through an additional Blueprint smart contract for governance. Upgrades should not overwrite previous versions to protect against malicious updates to active and future services. Instead, upgrades allow for a form of Operator lock-in, enabling developers to quickly benefit from the success of existing services and pass liquidity, as users can request "new versions" of the Blueprint while accessing the already restaked capital from the success of previous versions.
 
-Blueprints empower developers to create, customize, and monetize technical service configurations on the Tangle Network, defining features, behavior, resource requirements, and the Gadget binary for services such as Threshold MPC, zero-knowledge provers, AI infrastructure, and more. Developers can programmatically incentivize Operators to restake on their services and update them to improve and benefit from their long-term success. Tangle Blueprints are designed for reuse by various users and projects.
+Blueprints empower developers to create, customize, and monetize technical service configurations on the Tangle Network, defining features, behavior, resource requirements, and the Gadget binary for services such as Threshold MPC, zero-knowledge provers, AI infrastructure, and more. Developers can programmatically incentivize operators to restake on their services and update them to improve and benefit from their long-term success. Tangle Blueprints are designed for reuse by various users and projects.
 
 ### Consumers