Magnet Coretime

Magnet aims to implement a mechanism to dynamically purchase computing resources (core time) and trigger order logic when specific conditions are met. This plan covers modifications to both Node and Runtime parts.

Node part

1. Monitoring Relay Chain Blocks:

• Implement a monitoring task in service.rs, created through task_manager, to specifically monitor the latest best block notification of the relay chain. This task is responsible for continuously tracking updates to the Relay Chain blocks.

• When a new relay chain best block is detected, in addition to obtaining relevant information through the Runtime API, you also need to query the block to see if there is an event of placing an order, and obtain the account number and fee for placing the order from the event.

2. Check order conditions:

• Monitor new transactions in the transaction pool and accumulate gas fees for transactions to determine whether the order threshold has been reached.

• If the conditions are met (for example, the gas fee of the transaction pool reaches the set value), the logic of placing an order is triggered, and the place_order transaction of the relay chain is constructed and submitted through RPC.

3. Order logic:

• When the conditions are met, the Node part will construct and sign the place_order transaction of the relay chain and submit it to the relay chain through RPC. This step is now implemented in the Node part and is no longer called through the Runtime API, but is handled directly by the Node, including verifying whether it has the authority to place an order and whether it is the node's turn to place an order.

4. Carry proof information when generating a block:

• Collator contains inherited data when generating blocks and carries proof information for placing orders, which is used for verification when synchronizing blocks in parallel chains.

Runtime part

1. Runtime API:

• The Runtime API now mainly supports the recording and query functions of order information, including obtaining the last scheduled relaychain block height and hash value, bid information, etc. The buyCore function has been removed, and this logic is directly implemented by the Node part.

2. Pallet modification:

• The definition of the order structure remains unchanged, containing necessary order information such as order number, relay chain block hash, height, orderer, price, etc.

• Storage items also include order serial numbers, order list, current orderer, relaychain block information, bid, etc.

• Implement the on_initialize method to update the order status at the beginning of each block. The checking of order conditions and execution of order operations have been moved to the Node part.

3. New features of Order Pallet:

• Verify inherited: Verify the validity of the order.

• Query Interface: Provides a query interface, such as querying the order information in the relaychain block, the order threshold of the trading pool, etc.

• Parameter Settings: Allows you to set the block interval for placing orders and the order threshold for the trading pool.

After adjustment, this comprehensive design plan more accurately reflects the mechanism for dynamically purchasing computing resources in the Node part, as well as the division of responsibilities for processing order information recording and querying in the Runtime part. This design ensures that the parachain can efficiently and safely execute order logic based on the latest block information of the relay chain and the status of the transaction pool while maintaining the flexibility and scalability of the system.