hirosystems / chainhook

Extract transactions from Stacks and Bitcoin and build event driven re-org resistant indexers and databases.
GNU General Public License v3.0
158 stars 65 forks source link

Include "nonce" as part of the event stream response #422

Closed sabbyanandan closed 1 year ago

sabbyanandan commented 1 year ago

As a user, I want to use "stx-address" along with the transaction's "nonce" as a combination to prove/confirm that something is complete. To do that, I am using Chainhook to observe transaction events and are expecting the "nonce" as part of the event-streams.

Using the Stacks Blockchain API to get the latest "nonce" via https://docs.hiro.so/api/get-the-latest-nonce-used-by-an-account is certainly an option; however, I could avoid an extra call.

Requested by: https://zeroauthority.xyz/

SushilBro commented 1 year ago

In addition, if we got the hex value of the response given by the function call like in blockchain api then it will be easier for us to deserializeCV.

MicaiahReid commented 1 year ago

I'd be interested in hearing @lgalabru's thoughts on this as well, but here are my thoughts.

From looking at the stacks network README documentation on what data is included in a new_block event, which is the event that Chainhook ingests when maintaining an index and processing predicates. There is no nonce available as part of the payload.

But, the raw_tx field can be deserialized to retrieve the transaction's nonce for non-burnchain transactions. Here is an example of deserializing a raw transaction with stacks.js: snippet

Since the nonce is not part of the payload, for Chainhook to get this data it would still need to make a request. This means the extra call would still be happening, but instead of it happening only when a user needs the data, it would always be happening. So I don't think it would be best to include the nonce directly in the payload.

Let me know if I'm missing anything! @sabbyanandan, can you relay this to the Zero Authority team to see if processing the raw_tx field is sufficient for them?

lgalabru commented 1 year ago

I am not sure I understand the feedback. The nonce should already be part of the payloads being sent to predicates observers. https://github.com/hirosystems/chainhook/blob/ec76f29dd95818f2645f04d61ebaf3a8af1bad87/components/chainhook-types-rs/src/rosetta.rs#L212 The value of this field is inaccurate?

MicaiahReid commented 1 year ago

@lgalabru, we're stripping it out when serializing 🤦 https://github.com/hirosystems/chainhook/blob/5503c3d64d9f116bfd4cf71dfbe365b74219ec8d/components/chainhook-sdk/src/chainhooks/stacks/mod.rs#L529

I can get a fix out.

lgalabru commented 1 year ago

ha good catch, thanks!

MicaiahReid commented 1 year ago

In addition, if we got the hex value of the response given by the function call like in blockchain api then it will be easier for us to deserializeCV.

@SushilBro, the blockchain API returns a transaction result like this:

 "tx_result": {
    "hex": "0x070c0000000302647801000000000000000000000022ecb25c0002647901000000000000000000000129b96a4b9406737570706c790100000000000000000000011733124a14",
    "repr": "(ok (tuple (dx u150000000000) (dy u1278716038036) (supply u1199152712212)))"
  }

Chainhook attempts to deserialize the hex result and just returns:

"result": "(ok (tuple (dx u150000000000) (dy u1278716038036) (supply u1199152712212)))"

and if it fails to deserialize, it just returns the raw result.

Since we're already deserializing the transaction result, would you still need the hex so that you can deserialize it?

MicaiahReid commented 1 year ago

Also, @SushilBro, I've made a new issue for this just so we can track them independently. Let's continue the conversation here: #431