permaweb / ao Goto Github PK

Allow specifying the bundler used to publish like:

ao publish -b https://node2.irys.xyz -w ... contract.wasm

• Move Dev CLI CI over to be JS based using the Irys SDK and Warp-Contracts SDK (so many dependencies 🤢 )
• Add Step to update ANT Contract setRecord for subDomain install

{
	function: "setRecord",
	subDomain: "install",
	transactionId: installTxId,
}

If the user just calls ao on the command line print the output as if the user called ao --help

The hyperbeam CLI needs a publish command that will publish the built Wasm to Arweave with the appropriate tags:

{ name: "App-Name", value: "SmartWeaveContractSource" }
{ name: "App-Version", value: "0.4.0" }
{ name: "Content-Type", value: "application/wasm" }
{ name: "Contract-Type", value: "hyperbeam" }

• Implement publish module
• Build as part of p3rmaw3b/hyperbeam image
• Hook into publish command
  • ability to pass wallet path using -w
  • ability to pass contract Wasm path as parameter

hb init foo

This script will create the new directory, and create two files:

• hb.config.json // a project configuration file for the hyperbeam smart contract service
• src/main.lua // main lua smartweave file

• initial state is simply null
• tags passed to the handler are now just the raw array of { name, value } objects, from Arweave
  • Test contracts will need to use new format for tags
• handler now accepts (buffer, message, ao)
  • setting up handler returns a Promise
  • invoking the handler does not return a Promise
• Persist state as buffer instead of object, as part of eval
  • update zod schemas

These will be separate documents in persistence that purely contain an _id field equal to the computed message id. Prior to evaluation, we will query the db, and if the message id exists, then we will simply skip over the message and not perform an evaluation.

• result.messages should contains all messages emitted across the range of interactions evaluated (accumulate array)
• result.output should contain all out emitted across the range of interactions evaluated (accumulate string, separated by newlines)

Also, we may want to consider a few helper commands for irys.

ao irys 
ao irys fund [amount]
ao irys balance

ao irys -w [wallet]:

• Description: Returns Irys balance

ao irys fund -w [wallet] -h [node] [amount]:

• Description: funds irys node with AR, amount is in AR

ao irys -w [wallet] balance:

• Description: returns the balance provided in Irys

Thoughts?

• send
• receive
• spawn

Is this the same thing @TillaTheHun0 / @twilson63 #21?

The hyperbeam dev-cli will need to be published to arweave, along with an install script to install that specific version of the cli.

Since we do not know the transaction that will contain the binaries until we publish them

• Create build script to build the binaries
• Create install script to install the binary for the specific platform ie. mac, windows, or linux
• Create CI to publish binaries then. install script pointing to the transaction that contains those binaries
• Way to keep track of transactions that contain binaries and install scripts

• can send and receive messages
• when receiving a message, increment counter and keep record of who (which process/contract) incremented

• result.spawns should contains all spawns emitted across the range of interactions evaluated (accumulate array)

As part of #117 , I disabled the SDK integration tests, until we have some ao processes we can use in them.

This issue just tracks turning those back on, so that we don't forget about it.

Using Lua, docker and emscripten create a cli tool that can be used to compile lua scripts into wasm. The tool will need to wrap the lua contracts in a main lua function that deserializes the incoming JSON string and serializes the outgoing table into a json string.

• create project
• create README with usage directions
• #3
• #5
• #7
• create a packer module that packs lua scripts into a single file
• create source map for lua/wasm
• create docker container
• publish docker container
• create binary builds for hb cli
• create wasm contract deploy script to arweave using bundlr
• created ao-loader to manage the loading of ao contracts
• created ao-sdk to use in the compute unit and handle the basic functions for ao

• index.js sdk readState doesnt work properly, readState works when configured as it is in main.test.js
  - [ ] #34
• after deploying a contract the sdk throws an error when trying to readState if the block is null in gql
• evaluating contract VkjFCALjk4xxuCilddKS8ShZ-9HdeqeuYQOgMgWucro after a writeInteraction receiving following output failed to call handle function error: [string "json"]:753: expected argument of type string, got nil
  - [ ] #38

• test cranking same tx twice, should not try to replay the messages
• test if 2 message chains rely on the same state. if 2 people crank a tx to receive a balance of 1 and there's only 1 to give one message chain should fail.
• the above may also leave contracts in a state of disarray contracts should be able to rollback to there healthy state.
• if the messenger server shuts off and its in the middle of cranking a message chain, when rebooting the server the messenger should be able to pick up where it left off.
• contracts should receive a failed message and handle that themselves
• 2 relayers receive the same transaction
• infinite message loop, the mu never reaches a state of receiving no messages
• sequencer or cu network request fails in cranking process
• sign the same transaction and send it to 2 relays

As described in https://hctzqejcuudjfi4t5lfxlp7vgrxflkdvikmigkyy7kecn6rpgjhq.arweave.net/OKeYESKlBpKjk-rLdb_1NG5VqHVCmIMrGPqIJvovMk8

• #98
• Results endpoint `/result/:messageId
• Scheduled Messages endpoint /scheduled/:processId?[from=messageId]&[to=messageId]

Much of the logic between the endpoints will be shared and reusable. So once I have /state done, the others will be able to piggy back off of that work.

• test U that lets users mint 1 per day
• Sends test $U to another process
• Show an example of a rejected transfer
• tests
• sample UI

Something like this:

• Expose command on CLI
• allow passing tags
• allow passing initial state
  • as stringified JSON -> Init-State tag
  • [ ] point to transaction -> Init-State-Tx tag
• allow specifying Contract-Src

We should check if docker exists then print a message if docker is not installed.

• repl
• run
• build
• publish
• contract

• Bump latest version of ai SDK
• contract -> process
• Add proper tags to ao source as part of ao publish?

add docs in ao site and readme's

• intro to lua
• intro to cli
• actor oriented messaging
• sdk usage
• js vs lua
• square away readme's

• game of life
• 3 contracts having a conversation
• game of life each block as a contract

This task is to build out the compile to wasm function

hb build 

This function will call

docker run -v ${PWD}:/src hyperbeam/dev emcc-lua

Right now only a single page of 5000 are fetched from the warp sequencer. We need to implement fetching multiple pages and combining the results in the Warp Sequencer Client.

See

With the move to be DataItem centric, ao will no longer share many semantics with SmartWeaveContracts:

• Init-State will not be required, and instead any tags can provided on the initial process spawn, which collectively will serve as the "initial state"
• Contract-Src will still be required and the rules therein will be the same ie. "must be an ao Contract-Type

In addition to changing semantics, ao will also no longer use the Warp Sequencer, and therefore will not need to register the ao Process at the Warp Gateway (in order for the Warp Sequencer to sequence properly)

The ao SDK will need to implement these new rules

• Remove accepting initial state, and instead just accept tags
• Remove registering the Process with the Warp Gateway, and instead ??? (register with AO sequencer?)

With ao publish we should check if the user has a funded wallet on Irys.

And let them know they need to fund their wallet on Irys in order publish

This server needs to expose an endpoint /crank/:tx this endpoint takes a interaction id to connect to know which messages to crank.

Look at subscribing to the contract to get notifications and cache them in the server.

• Read /messages endpoint to get outbound messages
• Sign the messages
• Dispatch messages to warp sequencer

const result = await warp.contract(CONTRACT).connect(signer).evaluationOptions(options).writeInteraction(input)

// subscribe to events from that contract
// need an internal pub/sub mechanism to trigger when messages are available
// get those messages and subscribe to events and repeat

create an ao-sdk that supports the readState

• load contract source
• load initial state
• load interactions (according to sort key height)
  • Check local cache for cached state and messages using sort key height
• evaluate the state
  • save each intermediary result to local cache
• return result

I propose the following protocol/layout for the messenger/sdk

A .drive(muAddress, txId, callBack) (or .crank) is added to the sdk. This can be called immediately after a writeInteraction or any time later down the line. This opens a websocket to the mu and sends a request for status on a txId. The status will be a JSON response 1 of 4 things

{status: "NONE", info: {...message etc}}
{status: "SUCCESS", info: {...message etc}}
{status: "FAILURE", info: {...message etc}}
{status: "PROCESSING", info: {...message etc}}

PROCESSING means the messenger is still cranking, NONE means cranking never started.

When the sdk receives a SUCCESS or FAILURE it will call the callback sent into .drive() or .crank()

Title says it all.

As part of this, I may also try to automate update install_ao g8way, if I can figure out how to add to CI

Move setting up install_ao ANT contract to a separate issue, so as to unblock X64 Mac users asap

The CLI needs to build a wasm file that contains the following methods:

• spawn - creates a new process
• handle - processes a message
• read or readState?
• close - frees process

The loader will need to implement the pause and resume methods to allow the cu to stash the state as memory.

• pause - will take a slice of the HEAPU8 and return it to the caller
• resume - will take an array and set it on the HEAPU8

This version is built with emscripten, but as long as the abstraction is consistent, we should be able to build a version of the loader that handles wasi and the cu can support both emscripten and wasi implementations.

The loader will also surface the spawn and handle process to the cu to be called.

As described in https://hackmd.io/fb6-25ccQbe7Ffg4uDVNdg

• move readState from SDK into cu (done by @VinceJuliano)
• refactor readState in SDK to fetch from cu endpoint

• add a new endpoint the the dre node /relayer/crank

input:

• contractId (i think)

Right now, the inner shape of a failed evaluation (implemented using a transduce) is being exposed when readState returns.

Instead, the SDK should unwrap the value from the transduce and return that instead

We'd like to provide an API for Lua SmartWeaveContracts to:

• send messages to another contract (by way of returning a properly formatted results output)
• receive messages from other contracts (by way of returning a properly formatted results output)
• spawn new contract instances (not sure on this mechanism yet. Maybe expose on results?)

We need to decide on what inputs are required, validate those inputs, and then determine a way to expose to the contract.

• send
• receive
• spawn
• mechanism to expose AoMessages and show that it works as part of a contract invocation

Right now the relay is all in memory so if something fails theres no way it can pick up where it left off cranking. If someone requests cranking on a tx it should pick up where it left off and not try to crank the same messages

Contracts are often created programmatically. The ability to create an AO contract, using the SDK, would be great for those use-cases.

• Expose createContract api
  • accepts initial state as JSON
  • accepts txId for contract source
  • adds necessary tags and publishes to Arweave

Questions:

• Any other actions that need to be taken ie. w.r.t the sequencer?

Right now, the cache is blown away on each deploy. This works well in the development stage when the cache shape is in flux.

Eventually though, once the cache shape and debugging is more stable, we'll need to mount a Render Disk and allow placing the PouchDB files on that persistent disk, so the cache will persist across deploys.

This module is deprecated and needs to be marked as such using the npm cli, and made to point to the new loader

Since the packages will be published under the @permaweb scope (@permaweb/ao-loader and @permaweb/ao-sdk), I wasn't able to publish the packages without first needing to login to NPM CLI using the account that issued the Auth token (I think an account owned by @twilson63?)

So once the packages are registered under that scope on NPM, they can be published be CI using the token.

• Register the @permaweb/ao-loader module on NPM
• Register the @permaweb/ao-sdk module on NPM
• Publish the @permaweb/ao-loader module on NPM (can be done with CI)
• Publish the @permaweb/ao-sdk module on NPM (can be done with CI)
  - [ ] #54

/message - sends a message to su and does the cranking
/spawn - creates a new AO contract and sends it to the su
/monitor - watches a process for implicit actions and cranks those actions

The ao build script should support require lua files based on path.

We've settled on ao as the new name for the hyperbeam project. So we need to account for this in the project.

• Rename CLI from hb -> ao
• Rename docker image from hyperbeam -> ao
• Replaces instances of hyperbeam and hb in code with ao
  • Directions in install script
  • Binary name
  • Contract-Type used by CLI and modified Warp SDK
  • loader module name

• accepts processId and to (messageId)
• loadProcess
  • verify type is "process"
  • gather tags as state
• loadSource
• loadMessages
  • load sequenced messages from SU
  • load scheduled messages based on tags and range being evaluated
• evaluate each message
  - [ ] verify Data-Item (not sure how to do this)
  - [ ] calculate messageId
  - [ ] if forward-for, check the cache for if message is already evaluated