Introduction

Morpheus aims to enhance the development of a peer-to-peer network that includes personal, general-purpose AIs known as Smart Agents. These agents are capable of executing Smart Contracts on behalf of users. Through providing open-source Smart Agents and large language models (LLMs) that enable connections to users' wallets, decentralized applications, and smart contracts, Morpheus seeks to make access to AI and the crypto ecosystem universally accessible.

In the Morpheus ecosystem, four principal groups of stakeholders contribute to and benefit from the network's expansion:

1. Coders - These are the open-source developers within the Morpheus network who design the smart contracts and off-chain components that fuel Morpheus. This group also includes developers who construct smart agents leveraging Morpheus.

2. Capital Providers - These stakeholders in the Morpheus network are the ones who allocate their staked ETH (stETH) to the network's capital pool for utilization.

3. Compute Providers - These contributors offer neutral computing resources, predominantly through GPUs, to support the network's operations.

4. Community - This segment includes stakeholders who develop interfaces to engage with the Morpheus network and its smart agents. It also covers any individuals contributing tools or efforts to attract new users to the ecosystem.

In this article, we delve into the mechanics of compute provision within the Morpheus network, alongside an analysis of Erik Vorhees' 'Yellowstone Compute' model, which serves as the foundational infrastructure for Morpheus.

Compute Provision

First, let’s understand the role of a compute provider in the Morpheus network. Compute providers are entities running full nodes that provide access to computation resources to allow users to access inference from models that cannot be handled locally. They typically will operate Graphical Processing Units (GPUs) either on-site, in the cloud or via DePIN’s such as Akash, Render or IO Net. Essentially the compute providers allow users access to the outputs of computationally intensive models and in return they are rewarded with MOR tokens for each successful interaction with a user.

This mechanism is similar to the Proof of Work (PoW) consensus that the Bitcoin network runs on. Miners in the Bitcoin network are rewarded with a BTC block subsidy for each successful block they validate and build. Compute providers find utility in the MOR token in a couple of ways:

1. Qualification - To qualify as a valid compute provider for the network and receive compute requests from the router, the compute provider's public address must hold MOR tokens. This is to dissuade Sybil attacks.

2. Payment - Operating the infrastructure to facilitate compute requests is costly. GPU’s are expensive and they require a large supply of power to operate, on top of the Devops work that goes into successfully fulfilling requests. The MOR payment for compute therefore acts as revenue for the provider and enables the Morpheus compute network to dynamically service compute requests via the free market. For example, if demand for compute is low and the supply is high, the most inefficient providers may be operating at a loss and will leave the network until an equilibrium is reached. This dynamic also incentivises the most efficient compute providers to facilitate requests, since they are able to offer the lowest bids to the router (this could be through access to the long-tail of GPUs or cheap energy sources throughout the world). Simply, the software pays for the hardware.

White Paper Solution

The original Morpheus whitepaper, published on the 2nd of September 2022, described the compute provision mechanism like this:

“The pro-rata MOR transaction fees burned by each Compute Provider serves as proof of the Compute Providers status and earns a proportion of the MOR tokens each day.

For example, if there are 100 Compute Providers on day 1 when the network launches, then each one gets a pro-rata reward based on the amount of MOR they have burned via fees. In this case, presuming each of the 100 compute providers burned 100 MOR, then 1% of the 3,456 MOR tokens each day = 34.56 MOR.”

In this case, a user would pay for inference with a blockchain transaction each time they utilized the  Morpheus compute network and the routing of compute requests would be decided based on the quantity of MOR the compute providers public address held. Under this model, we encounter four major issues:

User Costs - Under this model, each time a user accesses inference they have to pay a fee in MOR via a blockchain transaction. Even post the Dencun upgrade, the gas costs associated with accessing this inference quickly become uneconomical as each inference is an extremely low cost (gas costs could be greater than the inference cost).

UX - Requiring users to complete a blockchain transaction for each inference access results in a poor user experience. Unlike OpenAI or Google, where inference is quick and seamless without the need to sign transactions, this requirement could render Morpheus a less competitive option.

Game-ability -  Under this model, all MOR compute emissions would be distributed pro-rata, making the system highly vulnerable to exploitation due to the significant gap between expected revenue for compute providers and the actual costs of computing. An adversary could potentially spam/sybil their own Compute Provider node with inference requests, thereby earning a substantial amount of MOR tokens daily without delivering any real economic value. This situation could result in an abundance of early compute resources being unused, which would likely vanish as the exaggerated revenue prospects decline. Consequently, the MOR tokens allocated for this early incentive would be effectively squandered.

Performance - In this model, the routing and matching of a compute provider and a user is based on the quantity of MOR the compute provider holds, meaning the routing is agnostic to performance. Under this model, determining priority in inference handling misses the mark on critical performance indicators like response speed and the efficiency of inference processing. Optimizing for these aspects — minimizing both the time it takes to respond and the cost associated with computation — should be the network's primary goal.

Yellowstone Objectives

Recognizing the shortcomings of the initial setup, Erik Vorhees released the “Morpheus ‘Yellowstone’ Compute Model” paper on January 3, 2024. This document aims to more closely align the compute provision mechanism with the network's overarching objectives. Those objectives are:

1. Align Incentives - Create fundamental economic demand for MOR in a manner that's sound and sustainable.

2. Improve UX - Allow users the convenience of accessing compute without the need for payment per inference, aiming for a model where they ideally incur no costs in order to compete with their centralized counterparts.

3. Improve Game Theory - Ensure the provision of permissionless compute resources is efficient, scalable, and sustainable, without leading to excessive compensation.

4. Improve Performance - Encourage free-market competition among compute providers with incentives for lower response times and reduced costs.

5. Reduce Costs - Minimize the total number of blockchain transactions needed, thereby reducing the associated gas fees and facilitating highly scalable compute requests.

Yellowstone Mechanics

First, we must define each component of the system:

1. Users -  refer to any entities possessing a MOR address who submit requests to the Router for computational services. This group may include individual persons utilizing a Morpheus desktop node, automated bots, or corporations and third-party websites engaging with the Morpheus network on behalf of their clients. It is crucial to note that these third-party "end-users" are not considered Users in the context of the Morpheus network.

2. Compute Providers - are entities operating a node that supplies computational resources, holds a MOR address, and submits IPS (Inferences Per Second) bids to the Router. Upon winning a bid, a Provider offers the computational resources (such as GPUs) necessary for executing the AI model requested by the User.

3. Router - is a software application equipped with a MOR address that orchestrates the market interactions between Users and Providers. It is responsible for registering Providers' addresses and bids, processing requests from Users, recording the execution times and outcomes of these requests, and directing the Compute Contract to compensate qualified Providers with MOR payments. The Router neither initiates nor receives any MOR transactions or transactions on any other blockchain and does not access the content of requests or their responses.

4. Compute Contract -  is a smart contract with a MOR address, tasked with collecting all MOR designated for the Compute allocation, keeping track of amounts due to qualified Providers, and disbursing MOR payments to Providers upon their request.

“Inferences per Second” (IPS) is the basic measurement unit for AI inferences, serving as a benchmark for rates within the Yellowstone router. Hence, the significance of a single Morpheus AI inference is measured by this unit.

“IPSMax” indicates the Router's upper limit for IPS that can be compensated.

The Yellowstone compute model works as follows:

1. Users, compute providers, and router all create MOR public keys and private key pairs.

2. If a user holds any balance of MOR, they may submit a signed Request for Compute “RFC” message to the Router. The user specifies [LLM] and [IPSMax].

3. The router prioritizes RFCs based on a user’s MOR balance, which helps to solve the sybil issue.

4. The router selects a compute provider that supports the [LLM], prioritized based on lowest Bid per IPS in MOR (cheapest cost of inference).

5. The router then sends a liveness check to the compute provider. If Pass, then:

6. The router connects the user to the Provider over TCP/IP.

7. The user sends a query using to the provider, using this notation: ‘[LLM],[prompt]’

8. The compute provider computes the query and sends the result to the user

9. The user reports success metrics to the router (such as IPSs received or time taken, or pass/fail vote)

10. The router instructs the compute contract to credit the compute provider with MOR if the job was completed satisfactorily.

11. Some time later, the compute provider requests payment of MOR from the compute contract and the compute contract sends MOR payment if valid (first blockchain TX so far, can be batched).

Yellowstone Outcomes

The Yellowstone compute model improves on the original model and achieves its set out goals in a number of ways. Let’s analyze the outcomes of this compute model:

1. User Experience - The user receives a fast result for their query and doesn’t pay anything (only holds MOR). This leads to superior UX and thus should improve adoption.

2. Performance - The compute contract paid for access to compute through a competitive bidding process (lowest bid per IPS) and implemented a quality check to ensure the result was satisfactory. This free market, competitive process will drive the costs for inference toward the price of base electricity. This way, the most performant compute providers will win, either through superior management or cheaper access to compute / electricity.

3. Costs - The costs of inference are driven down via free market mechanisms, but also through the usage of offchain systems and limiting the number of blockchain transactions that must be completed. In this model, the only blockchain transactions that must be completed are the compensation of compute providers, which can be batched together and completed on set intervals. Users can freely access compute without having to pay exorbitant gas fees.

4. Improved Game Theory - In the Yellowstone model, a compute provider is only compensated with MOR when they have successfully provided compute. In the original model, the compute provider emissions would be fully distributed pro-rata, enabling users to sybil / spam their own hardware with requests to acquire MOR cheaply. The somewhat random selection of providers in the matching process coupled with compute providers only being paid for successful outputs, help reduce this issue.

5. Privacy - The offchain router provides reasonable privacy guarantees. The query never touches the router and neither does the result. Providers are selected somewhat randomly and only know the IP address of the user.

The Compute Budget

As discussed, the compute contract is a smart contract which receives all of the MOR emissions allocated to the Compute bucket. It tracks the amounts owed to eligible compute providers and facilitates MOR payments to these providers upon their payment request.

The Morpheus Network establishes a daily 'compute budget,' reflecting the maximum amount of MOR the network is prepared to allocate for computing services each day (starting at 3456 MOR per day). Consequently, the compute contract is authorized to disburse up to this MOR limit in compensating compute providers for their contributions. The product of this allocated MOR amount and its prevailing market price determines the network's daily budget in dollars for securing compute services. This way, the contract will be solvent so long as MOR paid < MOR earned per period from emissions. In reality, this budget will be a fixed percentage of the compute contracts MOR balance at the end of the prior day, ensuring that the contract never runs out of MOR as the balance decays asymptotically.

For example, if we take 50% of the compute emissions as the ‘compute budget’, we get the following emissions schedule for compute providers, assuming the compute started when the capital contribution contract went live and the entire budget is distributed each day.

However, since we have a 90 day bootstrapping period for the network, at launch there will be 312,069 MOR in the compute contract, meaning the compute budget will be higher in MOR terms. The compute budget is relevant since fundamentally, the Morpheus network manages the limited resources of IPS production. There is therefore a maximum amount of inference that can be accessed per day. Via this"AccessRate" mechanism, inference is provided to users, with this rate essentially specifying the daily access to IPS that each MOR token provides. Taking an example:

AccessRate is presented as the amount of IPS accessible with 1 MOR token (e.g., 1 MOR = 15,000 IPS). It is influenced by MaxIPS, which represents the network's maximum daily purchasing capacity for IPS.

MaxIPS = ((MOR Compute Budget * MOR Price) / IPS Price) * 1000

AccessRate = (1/MOR Supply) * MaxIPS

UserMax = AccessRate * User's MOR balance

Example at Launch:

MOR Supply = 1,300,289 MOR tokens

Prior Day Compute Contract Balance = 312,069

MOR Compute Budget = 3,120.69 MOR tokens per day (1% of above)

MOR Price = $50

IPS Price = $0.0025 per 1000 IPS

User Balance = 10 MOR tokens

Example results:

​​MaxIPS = [(3,120.69 * $50) / $0.0025] * 1000 = 62,413,800,000 IPS (this is the maximum IPS the network can buy/produce each day)

AccessRate = (1/1,300,289) *  62,413,800,000 = 48.067 (thus each MOR token grants access to 48.067 IPS per day)

UserMax = 480.067 (a user with 10 MOR tokens can access up to 480.067 IPS per day)

Nirmaan

We are gearing up to deploy compute at scale in order to advance smart agent proliferation on the Morpheus network once compute and router contracts go live in May/June time.

Nirmaan aims to democratize access to compute provision. If you are interested in running compute on Morpheus, Nirmaan will be providing a white glove solution, aggregating compute from the most cost effective venues in web2 & web3 and expertly managing the Devops required to compete on the network.

If this is of interest to you, please reach out to @oxnirmata on telegram or email hello@nirmaan.ai for further details.