There's one big hurdle for pre-launch of the gadget / restaking system, which is to create a fully coupled / composable developer experience.
Coupled
What I mean by fully coupled is that in this one environment, a developer can create a new gadget, deploy that gadget, test the gadget all against a mock Tangle runtime. They can convince themselves that their protocol is ready and submit the extrinsic from their terminal.
To get a coupled experience, I'm thinking of
Augmenting the protocol-template with proper test environment, the Solidity templated contracts, everything out-of-the-box. Upon gadget create <name of gadget>, gadget test should succeed.
CLI that allows creating new gadget repos, testing them, deploying them.
Composable
What I mean by composable is that protocols (or their primitives) can be layered together in a nice way so that developers don't need to reimplement certain functionalities to build new gadgets. For example, if I want to build an oracle protocol that uses MPC to generate a single threshold signature of an oracle value, I would want to leverage one of the existing threshold signature gadgets (really its primitives), i.e. once all nodes have queried the oracle, they would be able to reuse the code that generates the threshold signature.
Food for thoughts, if we view or build everything as an Input/Output gadget, then surely composing should make a lot of sense. Outputs of one protocol as inputs to another would create a nice primitive.
Macros/abstractions
The gadget's macros and types are tightly coupled with substrate, substrate transaction clients, and other dependencies that make building simple gadgets not possible. We should make it possible to create a protocol and test it without any blockchain dependencies. Hooks like post should be special locations where an arbitrary transaction client can be used to make calls to a blockchain. If we can abstract certain things into traits so that we can test with slimmer dependencies, it'll likely make building the full service blueprint / gadget a lot more straightforward.
Can we leverage a trait system to be more configurable and more general and less dependent out of the box on large dependencies like substrate.
cargo machete on sub packages.
Separate protocol execution from submitting the result to a blockchain. The former is great, the latter should be context dependent (blockchain dependent).
Eigenlayer AVS interoperability
Can we use AVS protocols on Tangle and vice versa, use gadgets as AVS nodes on Eigenlayer. What are the minimal requirements to implementing this interoperability. Most AVS nodes are golang, can we run them as binaries in a gadget that executes binaries? Eigenlayer AVSs also listen to a job/task management hook, can we build our gadget to be able to consume tasks from that system?
Turn this into a trait and be able to abstract over any type of job / task scheduling listener
Overview
There's one big hurdle for pre-launch of the gadget / restaking system, which is to create a fully coupled / composable developer experience.
Coupled What I mean by fully coupled is that in this one environment, a developer can create a new gadget, deploy that gadget, test the gadget all against a mock Tangle runtime. They can convince themselves that their protocol is ready and submit the extrinsic from their terminal.
To get a coupled experience, I'm thinking of
gadget create <name of gadget>,gadget testshould succeed.Composable What I mean by composable is that protocols (or their primitives) can be layered together in a nice way so that developers don't need to reimplement certain functionalities to build new gadgets. For example, if I want to build an oracle protocol that uses MPC to generate a single threshold signature of an oracle value, I would want to leverage one of the existing threshold signature gadgets (really its primitives), i.e. once all nodes have queried the oracle, they would be able to reuse the code that generates the threshold signature.
Food for thoughts, if we view or build everything as an Input/Output gadget, then surely composing should make a lot of sense. Outputs of one protocol as inputs to another would create a nice primitive.
Macros/abstractions
The gadget's macros and types are tightly coupled with substrate, substrate transaction clients, and other dependencies that make building simple gadgets not possible. We should make it possible to create a protocol and test it without any blockchain dependencies. Hooks like
postshould be special locations where an arbitrary transaction client can be used to make calls to a blockchain. If we can abstract certain things into traits so that we can test with slimmer dependencies, it'll likely make building the full service blueprint / gadget a lot more straightforward.cargo macheteon sub packages.Eigenlayer AVS interoperability
Can we use AVS protocols on Tangle and vice versa, use gadgets as AVS nodes on Eigenlayer. What are the minimal requirements to implementing this interoperability. Most AVS nodes are golang, can we run them as binaries in a gadget that executes binaries? Eigenlayer AVSs also listen to a job/task management hook, can we build our gadget to be able to consume tasks from that system?