Technically, we can hard-code data in the transaction script (we used to do that a lot) - but that means every transaction script we create would be unique. Depending on the use-case, this may not be desirable - and in fact, we started to move away from hard-coding data into the scripts.

Instead, we now have a mechanism to provide inputs to transaction scripts. The way it works is as follows:

One of the non-deterministic inputs for the transaction kernel is TX_SCRIPT_ARGS. This is a single word that is placed on top of the stack before transaction script is invoked.
A transaction script can interpret this word as a direct input (i.e., ~32 bytes of data), or could use it as a key for an entry in the advice map. The the latter scenario, the amount of data can be unlimited.

The way all of this data is provided to the VM is via the TransactionArgs struct. This struct is then passed into the TransactionExecutor's execute_transaction() method.

On the Rust side, a transaction script could look like a function that takes a word - e.g., something like this:

impl MyScript {
    pub fn entrypoint(args: Word) {
        // here we'll need a mechanism to convert args into a vector of felts, this could use our
        // usual methodology of "unhashing" data into memory
    }
}

In the future, we could improve the ergonomics - maybe something like this:

struct MyScript {
    foo: u32,
    bar: u32,
}

impl MyScript {
    pub fn entrypoint(&self) {
        // the compiler would inject the code that would automatically "unhash" the args
        // and write the data into memory so that we could do something like `self.foo`
    }
}

These are just thoughts off the top of my head. Not sure if this is actually possible (or is a good idea).

Transaction script compilation #622

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions