feat: Process Boot Loader (ECHO)

[twilson63]

Issue Summary: Boot Loader Implementation for AOS Process

Background

Currently, when spawning an AOS Process, the first item in the inbox is the Process Data Item, but evaluation does not occur until the first message is sent. We need to enable developers to initiate a boot loader that allows submitting data to be evaluated immediately when the client makes a GET {CU}/result/{pid} request. This request will evaluate the process, passing itself as the initial message to be evaluated and nothing else.

Problem

To act as a boot-loader, the CU must support the client's GET /result/{pid} request to trigger evaluation without receiving any other messages. This capability would allow the process to load Lua modules from a package manager or set up global states before receiving additional messages or cron jobs.

Solution Proposal

Update to Process DataItem Spec if there is a new property On-Boot, the property can have a value data or a TransactionId, if this is set, then the CU/Process needs to evaluate script code.

Spawn(ao.env.Module.Id, { ["On-Boot"] = "data" })

or

Spawn(ao.env.Module.Id, { ["On-Boot"] = txId })

There may be complications with Nonces; currently, the first message assigned by a SU receives a Nonce of 0. If we cannot adjust the Nonce to treat the Process Data Item as the first (0) message, we may need to set its nonce to -1 as the "pseudo-nonce" for the process.

One potential approach (for any new processes) is to create an assignment data-item with a nonce of 0 and link it to the process, so the CU considers it the first message. This approach avoids the need to use -1 as a nonce.

The CU will then need to recognize when it is being asked to boot a process, as opposed to evaluating a message. This can be achieved by simply omitting the process-id query parameter typically passed to /result when evaluating a message. If no process-id is provided, then the CU will assume that the request is to boot a process and act accordingly.

Affected Units

• SU
• CU
• aoconnect

---

Action Items for Engineers

1. Evaluation Trigger on GET /result/{pid}:

   • Implement a mechanism to allow evaluation of the Process Data Item upon a GET /result/{pid} request without waiting for other messages.

2. Adjust Nonce Handling:

   • Explore the feasibility of introducing an assignment data-item with a nonce of 0, ensuring it is recognized as the first message. Avoid using -1 for the nonce if possible.

3. Boot Loader Capabilities:

   • Ensure the process can load Lua modules from a package manager or set up global states before other interactions.

4. Testing and Validation:

   • Verify the new boot-loader mechanism works as intended across SU, CU, and aoconnect units.

---

Feel free to reach out if there are any questions or further clarifications needed regarding this feature implementation.

[twilson63]

Note we need to add ability to init owner, so if I Spawn a process I can assign owner in boot loader

[VinceJuliano]

I believe the MU logic will have to change as well to call /result on the process id

[VinceJuliano]

ao Improvement Proposal 6

Add Boot Loader Capability

Status: DRAFT

Abstract

Currently at the ao protocol unit level, evalutation does not occur on a process until the first Message is sent. The first Message triggers an eval on the cu when the mu calls the result endpoint.

Motivation

As a result of this, users are forced to send a Message to initialize their Process with code and state after spawning. This is a cumbersome developer experience. A spawn action should be a single step. To do this the protocol will handle an On-Boot tag that defines a boot script either in the Data field of the Process, or as a transaction id.

Specification

Process Assignment

The SU will generate an Assignment DataItem for a Process when it is spawned. The Nonce tag on the Assignment will be the first index for the list of messages. So if the Process Nonce is 0, the first Message Nonce will start at 1. The Process tag on the Assignment will point to the Process DataItem. The Hash-Chain tag will be seeded and set in the Process Assignment tags.

Unit Behavior

mu

When the mu receives a Process DataItem to spawn it will send it to the su and then call /result/processid on the cu, and continue pushing.

cu

The cu will handle a request to /result/processid. It will load the Process DataItem and Assignment from the su and initiate a wasm evaluation with them.

The cu will also treat the process as the first Message in the stream for all new Processes. Meaning for any new Process the first Message it retrieves from the su Message list will be the Process. The cu should handle this accordingly, but also continue to work for old Processes where this is not the case.

su

When the su receives a Process DataItem, it will generate an Assignment with the above outlined specification. It will also make this Assignment available on the /processes/processid. It will also begin all Nonce sequences at the Nonce for the Process as opposed to the first Message. On the Message list return that is available at /processid the su should return this Process and its Assignment at Nonce 0.

Impact Analysis

When Spawning a new Process the user will now be able to spawn and initialize in 1 step. This will impact the internal logic of all 3 units, but mostly the SU and the CU.

The AOS process.lua will need to be changed to enable evaluation of either the data body, or the ability to read the provided tx via weavedrive to capture the lua code that needs to be evaluated. Then evaluate the lua code and return a result object.

Scope

All 3 unit types will be effected, as well as the specification for the Process, which will now have an Assignment

aos(process.lua)

• create a once handler, that listens to the first message which will be type Process and have the same Id as the process, if this message has an On-Boot tag and its value is data then this handler should call the evaluate function passing the data for evaluation. if this message has an On-Boot tag and its value is a txId, then the handler will need to read the txId from /data/{tx} and capture that string and pass it to the evaluate function for evaluation. Since the handler is a once handler it will remove itself from the list.

Security Considerations

Outstanding Questions

Summary

Adding an Assignment DataItem to the Process and modifying the behaviour of the units, will allow users to spawn and initialize in a single step.