feat: rust bindings for solidity facades

[sanderpick]

Solidity facades for use within WASM actors, e.g., for emitting events.

• Lays groundwork for full method facades. We want to move away from the contract wrapper approach to EVM compatibility--they are hard to maintain and add extra gas.
• The work here is based off internals of the forge bind command.
• Use make actor-facade to generate rust bindings, which produces the crate recall_sol_facade, which is used in ipc.
• Removes the events generated by the wrapper contracts in favor of the native ones, which means we get events from all tooling, not just JS libs / others that depend on the wrappers.

[sanderpick]

This is the actual API exposed via recall_sol_facade. Actors use features to select the needed internal modules.

[sanderpick]

This is the program that builds the facades from the .sol files. See file header comment for more.

[sanderpick]

Some helper types here to make the API easier to use.

[sanderpick]

the files below are the actual solidity interfaces.

[sanderpick]

@dtbuchholz we don't have to delete these now if your tooling relies on these wrapper events.

[dtbuchholz]

@sanderpick i currently have logic to parse the event data from the tx receipt, but it'd (mostly) be straightforward to remove them in js-recall. they don't add much value and just emit the input params.

however, the createBucket one is important because i parse the emitted cbor data to get the created bucket's address. we could either:

• leave the event as-is
• have the wrappers inherit the facade events, and emit the new events. then, i can tweak the js sdk accordingly

[dtbuchholz]

fwiw, the js-recall repo has this contracts repo as a submodule, and then it generates the abi bindings via a build script. so, as long as ipc is also pointing to the same contracts commit, then it wont be an immediate if we remove the events.

[sanderpick]

however, the createBucket one is important because i parse the emitted cbor data to get the created bucket's address.

do you parse the emitted cbor in js-recall? there are these machine events: https://github.com/recallnet/contracts/blob/sander/facade/src/interfaces/facades/IMachineFacade.sol#L4. would those work? the MachineInitialized one carries the new machine address. downside: it's emitted from the bucket, not the adm actor, so it doesn't know its "kind" (bucket or timehub). we could move it to builtin-actors where the "kind" mapping exists.

[dtbuchholz]

do you parse the emitted cbor in js-recall?

@sanderpick yeah, i parse the emitted cbor—here's an example.

would those work? the MachineInitialized one carries the new machine address. downside: it's emitted from the bucket, not the adm actor, so it doesn't know its "kind" (bucket or timehub). we could move it to builtin-actors where the "kind" mapping exists.

MachineInitialized looks like it'll work. for now, i think that'll do because the js stuff doesnt touch the timehub and mostly assumes everything is a bucket.

[sanderpick]

sounds good. ah, I mispoke, those machine events are emitted from the machine actor trait, not the bucket. but yeah, we can move to ADM actor and include the kind in the future.

[dtbuchholz]

nre—this was super easy to update! when i create a bucket with the BucketManager, all i have to do is parse the events for MachineInitialized. (you're probs already aware of this behavior lol but it works great with js tooling)

tx from bucket manager's `createBucket` method call:
{
  transactionHash: '0xfc058514c27bfe5ecca4048cc931620f439034337d865d58fce780d234e06a83',
  transactionIndex: 0,
  blockHash: '0xa458ca644dc18453b581bdf77db3ff5bfe7469c392a2824cd98e6bef327bd17f',
  blockNumber: 4881n,
  from: '0x90f79bf6eb2c4f870365e785982e1f101e93b906',
  to: '0xf7cd8fa9b94db2aa972023b379c7f72c65e4de9d',
  cumulativeGasUsed: 29861475n,
  gasUsed: 29861475n,
  contractAddress: null,
  logs: [
    {
      address: '0xff00000000000000000000000000000000000092',
      topics: [Array],
      data: '0x00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001a000000000000000000000000000000000000000000000000000000000000000',
      blockHash: '0xa458ca644dc18453b581bdf77db3ff5bfe7469c392a2824cd98e6bef327bd17f',
      blockNumber: 4881n,
      transactionHash: '0xfc058514c27bfe5ecca4048cc931620f439034337d865d58fce780d234e06a83',
      transactionIndex: 0,
      logIndex: 0,
      transactionLogIndex: '0x0',
      removed: false
    },
    {
      address: '0xff00000000000000000000000000000000000092',
      topics: [Array],
      data: '0x000000000000000000000000ff00000000000000000000000000000000000092',
      blockHash: '0xa458ca644dc18453b581bdf77db3ff5bfe7469c392a2824cd98e6bef327bd17f',
      blockNumber: 4881n,
      transactionHash: '0xfc058514c27bfe5ecca4048cc931620f439034337d865d58fce780d234e06a83',
      transactionIndex: 0,
      logIndex: 1,
      transactionLogIndex: '0x1',
      removed: false
    }
  ],
  status: 'success',
  root: '0x2c75370ed8af763670fabeb4281e5ae1c70a8def5a0556b5f7509d4927771c80',
  logsBloom: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',
  type: 'eip1559',
  effectiveGasPrice: 250029n
}

using viem to parse for `MachineInitialized` event gives us the `machineAddress` variable:
0xFf00000000000000000000000000000000000092

[sanderpick]

boom!! hell yeah