System
Last updated by tim a year agoGeneral Platform Architecture
Initially, Grindery Nexus will be introduced as a hosted service, following a similar approach to The Graph. However, it will gradually transition into a decentralized network comprising independent nodes.
A flexible language to compose workflows
Grindery Nexus is a comprehensive platform similar to Zapier, designed for Web3. It enables users and developers to create complex automations that connect smart contracts and off-chain systems. The available connectors determine the accessibility to Web2 APIs and Web3 chains. The system revolves around CDS, which describe interactions with specific systems and can be combined in various ways for flexible workflows. This language at the core of Grindery Nexus allows direct interaction with end users, benefiting Web3 dApp developers, end-users, connector developers, and blockchain APIs and nodes.
System Components
Grindery Nexus is composed of several independent components:
Orchestrator: The Orchestrator serves as the central component of the workflow engine. It manages a list of all workflows, signals triggers, dispatches workflow actions for execution and validation, and stores execution results in persistent storage (IPFS/Ceramic).
Beacon: Beacons are signaling services responsible for receiving events from Web2 apps and Web3 providers. They send WebSocket messages to the orchestrators to keep them informed.
Gateway: Gateways serve as interfaces for encapsulating Web2 services or Web3 blockchains into composable actions.
Workflow Lifecycle
The language and components described earlier enable the creation of complex workflows that follow this execution process:
Users create a workflow, which is then saved in a database and ultimately stored in a persistent storage system like IPFS when decentralization comes into play.
The Orchestrator works with the Beacon service to set up triggers. These triggers capture signals emitted by Web2/Web3 systems.
Orchestrator nodes transmit the workflow details to the Gateway service to execute the actions defined by the end user during workflow creation. The results are sent back to the Orchestrator and saved to IPFS.
This workflow lifecycle ensures that users can create intricate workflows and seamlessly execute them by leveraging the collaborative efforts of the Orchestrator and Gateway services. The signals from Web2/Web3 systems are captured, actions are executed, and the results are securely stored, enabling the smooth progression of each step until the entire workflow is fulfilled.
An interoperable world of apps
In summary, Grindery Nexus allows users to define workflows consisting of triggers and actions within their dApps. The platform stands out for its ability to create interoperable dApps with user-friendly integration. Workflows can be comprehensive, supporting multiple steps, delays, transformations, and branching. They can incorporate on-chain, off-chain, and cross-chain integrations across various blockchains. Triggers can be based on time, blockchain events, API events, and more. Connectors, which can be reused, enable payment for services. Grindery Nexus addresses the interoperability problem by facilitating seamless information exchange between previously incompatible Web2 and Web3 systems. This expands possibilities, connects diverse applications, and makes them more accessible to new users.
Decentralization of the Execution Environment
To create a comprehensive and secure solution that meets the diverse needs of users, Grindery Nexus will progressively transition into a decentralized network of nodes. This decentralization strategy aims to adapt to user requirements by establishing a peer-to-peer off-chain network of nodes. While centralized APIs like Slack and Google may not need decentralization for their interactions, it becomes crucial for inter-blockchain communication.
Our approach recognizes the importance of a customized protocol that considers the centralization or decentralization of the involved systems. Including every aspect of our workflows would lead to increased costs and decreased execution speed, which may not be necessary in all situations. For instance, integrating Slack with Google does not require on-chain storage and can be suboptimal if enforced.
The decentralization path involves several components of the system. Initially, the orchestrator, previously backed by GCP, will transition into a network of independent orchestrators. This decentralization ensures resilience against breakdowns, malfunctions, censorship, or inefficiency by building a trustless engine that distributes orders and collects information from different parties.
Similarly, the Beacon service will consist of multiple entities to avoid failures or disruptions. While decentralization is not the primary concern for capturing on-/off-chain events, multiple Beacons provide flexibility and reliability, especially considering the hazards that can affect rpc blockchains.
The most critical aspect of decentralization lies in the network of Gateway nodes, which actively interact with the blockchain, validate information, and write to the blockchain. The information from Beacons is validated through an off-chain consensus process, preventing single points of failure and ensuring the validity of the workflow. Network nodes validate information based on user-defined verification criteria, accommodating different levels of verification, including purely Web2 interactions or a combination of Web2 and Web3. Ultimately, Grindery Nexus can facilitate cross-chain messaging, enabling seamless integration between different blockchains within the Web3 ecosystem.
