How does a transaction on the lab-exchange work?
A transaction on the lab-exchange is a multi-step process. To break down the required steps, we illustrate an application call that includes the basic lab-reverse-complement service.
TODO - feature in development!
phase 1: transaction definition on the [client] side
- the client has installed the [openlab CLI] and created a [local wallet]
- the client lists the available [applications] using
openlab app list. In our example the service we focus on
- the client submits a job using
openlab job submit reverse-complement. During this step the command line is asking for input information interactively. In case the user prefers to use the tool without an interactive component, a JSON template can be exported, edited and submitted with the commands below:
# non-interactive submission of jobs on openlab:
# export the job instruction JSON object to a example_directory
openlab app example reverse-complement /example_directory
# edit the job instruction object locally
# submit a prepared job instruction instead of an interactive process
openlab job submit -t /target_directory/job-reverse_complement.json
phase 2: transaction submission on the [client] side
underneath the hood of
openlab job submit multiple functions are called:
- the job object, a JSON with the instructions, is generated. In our case
job-reverse_complement_20220408184322.jsonis stored in a local directory controlled by the client. An example for
- the job object is pinned on IPFS, giving us a
jobURIwhich will be needed when interacting with the smart contracts of the openlab exchange. The function call is
openlab file push job-reverse_complement_20220408184322.json.
- the client interacts with the lab-exchange exchange contract and calls the
jobURIof the job object is an argument of this function. The job is created and enters the
- optional: to facilitate the execution of services, the client can also share the job object directly with an [index service] maintained by the DAO via http. The service broadcasts all requests from clients to a collection of community-registered servers.
phase 3: transaction verifcation on the [provider] side
- the server checks the state of the openlab exchange contract by querying the subgraph for jobs within the
- the server pulls job objects via their
jobURIfrom IPFS and checks wether the requested service is within the repertoire of services that can be provided.
- optional: to facilitate the execution of services, the server can receive job objects from the [index service] and filters incoming requests before verifying them (step 1) and their job objects (step 2).
- the server interacts with the openlab exchange contract and calls the
acceptJobfunction, with the transaction's
_jobIdbeing the only input argument.
- the server validates that the
acceptJobfunction call was successful.
phase 4: transaction processing on the [provider] site
once the transaction is verified and claimed the server can get to work and process the request.
- the server accesses required information from job object, including the pulling of input data from IPFS
- the server takes the input information and starts the service. In our case the service is accessible via https://02wun6.deta.dev/ and the request from the server would look like
curl https://02wun6.deta.dev/ctatataaataaataaataaatattatatatatag. In a live deployment, where running the service was not for free, the server would protect the endpoint.
- the server collects all output data generated during job processing, and pins files to IPFS together with a metadata JSON object reffered to as the token object. The token object is referenced with a
tokenURIwhich is an input argument for the
closeJobfunction. An example token object is displayed below:
- the server calls the
swapfunction, which includes both the minting of a LAB-NFT, the transfer of that LAB-NFT to the client, the calling of
closeJob, and the claiming of funds held within the escrow.
phase 5: transaction end on the [client] side
In the near future, clients will be able to flag a transaction between receiving the LAB-NFT and release of funds from escrow.