How to index transaction of predicate execution?

[chlenc]

Hello everyone,

I am currently working on indexing transactions that occur when an order by predicate is being fulfilled. For this purpose, I have implemented an indexer, and you can find the code here: spark-indexer/src/lib.rs

The goal of my indexer is to capture transactions that indicate when my predicate order was fulfilled. However, when running the indexer, I am only able to see details of the predicate creation in my logs, such as:

2023-07-28T11:41:46.692671Z  INFO fuel_indexer::ffi: 55: ✨ Order slot ProxySendFundsToPredicateParams {
    predicate_root: 0x0a010060e8fc95d407cb04e7d643274d4bd4daa78db157272d11e5f6d9a86f89,
    asset_0: 0x17e68049bb3cf21a85f00778fde367465bbd8263e8d4f8e47e533fe0df865658,
    asset_1: 0xeaa756f320f175f0023a8c9fc2c9b7a03ce8d715f04ac49aba69d2b7d74e70b8,
    maker: 0xccc4f9249536cf89ab0f31bb52fa06c00ea0387dcac5830924ecf56f2dded3a5,
    min_fulfill_amount_0: 1,
    price: 300000000,
    asset_0_decimals: 6,
    asset_1_decimals: 9,
    price_decimals: 9,
}

While this information shows that funds were transferred to the predicate root, I am interested in capturing the transaction where my predicate was fulfilled and the required exchange tokens were transferred. In my current logs, this information is not being captured.

The specific block height where the required transaction occurs is 1664943.

To test the order creation and fulfillment, I run the following tests in my code:

1. Order creation: fulfill_order_test.rs#L143

2. Order fulfillment: fulfill_order_test.rs#L157

I am hopeful that someone can provide insight into whether it is possible to index the transaction I am looking for, and if so, I would greatly appreciate an example of code that demonstrates how to achieve it. Thank you, and I am eagerly looking forward to your reply.

[dmihal]

The ideal situation would be:

1. The indexer captures the "predicate announcement" and gets the predicate address
2. The indexer watches the predicate address (similar to how templates work on The Graph)
3. The indexer can index any transaction spending assets from the predicate address

No idea if this is possible currently

[Voxelot]

Followup up from what @dmihal mentioned, it looks like the first case is already being covered here in the OP with the event ProxySendFundsToPredicateParams.

Is the problem with 2&3 that we don't have an easy way to subscribe to particular predicate roots? Couldn't your indexer module just scan all the txs in each block to look for previously announced roots?

[ra0x3]

We had previously planned to work on something like this (roughly what @dmihal mentions) over in #886 -- following up on where/why that stalled.

[ra0x3]

@chlenc

• I'll be picking this up going forward
• Do you have any issues with the approach that @dmihal and @Voxelot mention?
  • This is most likely how this would be implemented
• We would add a parameter to the indexer manifest - similar to how we do with contract_id where you would add predicate roots and you would be able to filter TXs for this particular root
• With regard to timeline/ETA - not totally sure, I'm pretty buried under some other work, but the first step is just making sure this approach works for you

[Voxelot]

One potential issue is that predicate roots may be unique for each particular order, as they need to commit to the wallet address of the person who has the capability to perform cancellation logic. So they need a way to track predicate roots that are generated on the fly by a script transaction.

The part I don't understand is why we're unable to find the matching predicate roots even when scanning through all the transaction brute force, as this should be possible without any new features from the indexer. We likely need to run their code locally to find the issue.

[ra0x3]

@Voxelot

The part I don't understand is why we're unable to find the matching predicate roots even when scanning through all the transaction brute force, as this should be possible without any new features from the indexer

This is actually true @chlenc, this ☝🏽 requires no updates from the indexer, and can be done today.

@chlenc Do you have a repository that I can pull down to check this? As well as possible steps to reproduce what you're trying? Hopefully this might be a quick PR I can push to your repo.

[chlenc]

Repo: compolabs/spark-indexer
Branch: fuel-indexer
Link: https://github.com/compolabs/spark-indexer/tree/fuel-indexer

To run the indexer

## Shell window #1 ##
# clone repo
git clone https://github.com/compolabs/spark-indexer.git
cd spark-indexer/
# run local database in a docker container
docker run -d -p 5432:5432 --name my-postgres -e POSTGRES_PASSWORD=mysecretpassword postgres
# run fuel-indexer service
fuel-indexer run --run-migrations --fuel-node-host beta-3.fuel.network --fuel-node-port 80 --postgres-host 127.0.0.1 --postgres-port 5432 --postgres-password mysecretpassword --postgres-user postgres

Here you need open a new terminal window in spark-indexer folder and run

## Shell window #2 ##
forc index deploy

After that, in shell window #1 you can see that output

2023-08-07T12:26:32.425395Z  INFO fuel_indexer::ffi: 79: ✨ Order slot ProxySendFundsToPredicateParams {
    predicate_root: 0x0a010060e8fc95d407cb04e7d643274d4bd4daa78db157272d11e5f6d9a86f89,
    asset_0: 0x17e68049bb3cf21a85f00778fde367465bbd8263e8d4f8e47e533fe0df865658,
    asset_1: 0xeaa756f320f175f0023a8c9fc2c9b7a03ce8d715f04ac49aba69d2b7d74e70b8,
    maker: 0xccc4f9249536cf89ab0f31bb52fa06c00ea0387dcac5830924ecf56f2dded3a5,
    min_fulfill_amount_0: 1,
    price: 300000000,
    asset_0_decimals: 6,
    asset_1_decimals: 9,
    price_decimals: 9,
}

That is a creation of order, so it means that predicate tx will be in the next block.

I’m using logs inside an fn handle_block(block: BlockData) to find some txs similar to predicate calls

to trigger the indexer you can use this test:
https://github.com/compolabs/spark-rs/blob/master/tests/testnet_tests/fulfill_order_test.rs
Or this
https://github.com/compolabs/spark-rs/blob/master/tests/testnet_tests/cancel_order_test.rs

[ra0x3]

Sweet thanks for this @chlenc you should hear from me shortly :) .

[chlenc]

Sweet thanks for this @chlenc you should hear from me shortly :) .

Ok ser, thanks 🫡

[ra0x3]

Gonna close this, as this work is tracked in #886