[WIP] feat: predicate chaining #571
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Also separate `StacksPayload` and `BitcoinPayload` into separate types for easier client-side inference. Bump version to 1.8.0
When a Chainhook is triggered and we send a payload to a user, we filter some values based on user settings (`include_proof`, `include_inputs`, etc). This helps to reduce the payload size that is sent over the wire. However, when we created this payload, we were omitting these fields completely even though the corresponding type does not have those fields as optional. This makes using our SDK types for deserialization impossible. This PR adds in those fields in all cases and sets them to empty values if filtered out.
MicaiahReid
force-pushed
the
develop
branch
2 times, most recently
from
913d3d9 to
f0bdfc5
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces the concept of predicate chaining - one predicate can create subsequent predicates.
The first example of this is the bitcoin input predicate. It now has the "follow_inputs" field:
Consider the following chain of transactions:
Previously, this predicate would just allow you to find any bitcoin transactions that have a transaction input with
previous_output.txidequal to the providedtxid. So for the example, we could put thetxidfortx1, and the predicate would matchtx2, since it has an input that usestx1for its prevout.Now, by setting the
follow_inputsfield totrue, you can get all transactions that usetxidas input, and all transactions that use those subsequent transaction's id's as inputs. So for our example, providing atxidoftx1for the predicate would match fortx2(because it's prevout hastx1) andtx3(because it's output has a prevout oftx2) and so on.Notes
Here are some notes on where this PR is, since it doesn't look like I'll be able to finish this during my tenure at Hiro 😞
As this PR currently is, predicate chaining works in that we have a predicate that can create more downstream predicates. The part that is not yet working, and will probably get kind of messy is handling reorgs.
Reorgs will not only have to check against predicates to see if the user needs to be notified of blocks to roll back, but it also needs to actually delete predicates that were generated from reorged blocks.
Maybe the new predicates that can create other predicates have some metadata with them when they're created, such as the identifier of the block that created the predicate? As this is done, we should also implement a more general interface for this new type of predicate.