gizatechxyz / scarb-agent

All you need to build provable web3 Agents!
https://orion-giza.gitbook.io/scarb-agent
Apache License 2.0
2 stars 0 forks source link

Oracle Definitions Using YAML Schema #26

Open raphaelDkhn opened 1 week ago

raphaelDkhn commented 1 week ago

Currently, due to its fork of Cairo Hints, Scarb Agent uses protocol buffers to define messages shared between Cairo and an external server.

Now that we're using the YAML schema for the input and output of the Cairo program, I'm thinking of using YAML as well to define oracle requests, responses and services. This way, we have consistency with I/O, it's easier to support more complex data types, better DX, and we keep all cairo serde-related code in cairo-io-serde crate.

Here is an example of the yaml file for an oracle definitions:

schemas:
  Inner:
    fields:
      inner_field:
        type: Primitive
        name: u32
  Request:
    fields:
      w:
        type: Primitive
        name: u64
      x:
        type: Option
        inner:
          type: Message
          name: Inner
      y:
        type: Array
        item_type:
          type: Primitive
          name: i32
  Response:
    fields:
      n:
        type: Primitive
        name: u64

services:
  MyOracle:
    methods:
      oracle:
        input: Request
        output: Response

Wdyt @Gonmeso @EduPonz

Gonmeso commented 4 days ago

I think that this is incredible and that we could also leverage the power of YAML into this to merge the configurations, like servers.json and cairo_input.yaml into a agent_config.yaml.

Also, YAML usually supports anchors (example), which let us easily duplicate data if we need to, like the current url of the Python server.

Another thing is that adding Primitive, Array or Struct its duplicating information, as this can be obtain through the definition of the YAML for example:

Array

  Request:
    fields:
      y:
        - i32

Struct

  Inner:
    fields:
      inner_field: u32 # This is also how we can define a primitive
  Request:
    fields:
      x:
        inner: Inner

Options

  Inner:
    fields:
      inner_field: Option<u32>

Servers.json

schemas:
  Inner:
    fields:
      inner_field: u32
servers:
  - name: apy
    server_url: localhost:3000/apy # Also the name should be a reference, but we should not concatenate `server_url + / + name`
  - name: balance_data
    server_url: localhost:3000/my_balance
  # Also we could make that if url is missing we take the default url plus the name in this case
  - name: ironclad_data # here it whould be `default_url + / + ironclad_data`
options:
  default_url: localhost:3000

Also, is there a possibility to do something with Oracle.lock?

EduPonz commented 4 days ago

This is definitely the way to go IMO. In fact, we could also provide a YAML schema so we can:

  1. Ease the DX with autocomplete features in editors
  2. Validate input

merge the configurations, like servers.json and cairo_input.yaml into a agent_config.yaml

I think this is something I'd do as a second step, but the less config files the better for sure.

Also, is there a possibility to do something with Oracle.lock?

Again, I'd do this later as it involves updating other projects, but I also think we should look into it.