Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Event observer: additional info for burn operations #3517

Merged
merged 13 commits into from
Feb 3, 2023
Merged

Conversation

pavitthrap
Copy link
Contributor

@pavitthrap pavitthrap commented Jan 20, 2023

Description

Adds a burnchain_op field to transaction payload for the event observer.

In addition, it makes the json encoding of each burnchain op type more friendly to read. Examples of the readable versions for each op can be seen in the test suite of src/chainstate/burn/operations/mod.rs.
It does this through the function blockstack_op_to_json.

Modified an existing test in neon_integrations.rs to ensure this field exists & is populated.

Applicable issues

Additional info (benefits, drawbacks, caveats)

  • Leaving the names for the BurnchainHeaderHash serialization functions the same as the ones @kantai used in sBTC: Add burn ops RPC for PegIn #3511- in general I used all the same names/files he did so that conflicts would occur in a future merge & could be later be easily fixed.
  • There's one open concern I have around the serialization for PoxAddress. Right now, the serialization does not encode the optional AddressHashMode provided in a standard PoxAddress, meaning if this field is populated with Some, then when deserializing, it is set to None. I'm waiting for feedback from @kantai on this - I moved forward with this because this is what he did in sBTC: Add burn ops RPC for PegIn #3511, but just want to check all the same assumptions hold for the other burn ops that makes this lossiness okay.
  • In the future, I can consolidate some of serialization functions for the byte array types (like BurnchainHeader, BlockHeaderHash, VRFSeed). Right now the ser/deser functions are pretty much identical for a few types so it feels redundant.
    • I could create a hex trait associated with impl_array_hexstring_fmt, and move to_hex and from_hex to that trait. Then, I can create a serialization/deserialization function for a trait object. This would be done to prevent having to create serialization functions for types that are identical under the hood.

Checklist

  • Test coverage for new or modified code paths
  • Changelog is updated
  • Required documentation changes (e.g., docs/rpc/openapi.yaml and rpc-endpoints.md for v2 endpoints, event-dispatcher.md for new events)
  • New clarity functions have corresponding PR in clarity-benchmarking repo
  • New integration test(s) added to bitcoin-tests.yml

@pavitthrap pavitthrap requested review from kantai and zone117x January 20, 2023 21:11
@pavitthrap pavitthrap marked this pull request as draft January 20, 2023 21:12
@pavitthrap pavitthrap force-pushed the btc-tx-more-info branch 2 times, most recently from 27a6f34 to 8f1e5d6 Compare January 20, 2023 21:34
@codecov
Copy link

codecov bot commented Jan 23, 2023

Codecov Report

Merging #3517 (dab5d0b) into develop (37c7e12) will increase coverage by 34.14%.
The diff coverage is 52.38%.

@@             Coverage Diff              @@
##           develop    #3517       +/-   ##
============================================
+ Coverage    31.41%   65.55%   +34.14%     
============================================
  Files          298      240       -58     
  Lines       274979   130905   -144074     
============================================
- Hits         86381    85819      -562     
+ Misses      188598    45086   -143512     
Impacted Files Coverage Δ
src/chainstate/burn/db/sortdb.rs 81.70% <ø> (+41.18%) ⬆️
testnet/stacks-node/src/tests/neon_integrations.rs 85.17% <0.00%> (-2.17%) ⬇️
src/chainstate/stacks/db/blocks.rs 68.89% <50.00%> (+35.44%) ⬆️
src/chainstate/stacks/events.rs 66.66% <50.00%> (ø)
src/chainstate/burn/operations/mod.rs 45.67% <62.66%> (+14.90%) ⬆️
testnet/stacks-node/src/event_dispatcher.rs 83.63% <100.00%> (+0.11%) ⬆️
stx-genesis/build.rs 0.00% <0.00%> (-94.45%) ⬇️
build.rs 0.00% <0.00%> (-82.70%) ⬇️
testnet/stacks-node/src/tests/epoch_21.rs 88.68% <0.00%> (-7.45%) ⬇️
clarity/src/vm/version.rs 25.00% <0.00%> (-3.58%) ⬇️
... and 193 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@pavitthrap pavitthrap marked this pull request as ready for review January 23, 2023 20:56
@kantai
Copy link
Contributor

kantai commented Jan 25, 2023

@zone117x -- in the issue #2591, you mentioned that the API needs more information from events for things like the stack-stx operation to be processed correctly. This PR doesn't alter the "transaction events" portion of the event notifications, does that still need to be done, or did other changes to the PoX events solve that issue?

@zone117x
Copy link
Member

zone117x commented Jan 26, 2023

@zone117x -- in the issue #2591, you mentioned that the API needs more information from events for things like the stack-stx operation to be processed correctly. This PR doesn't alter the "transaction events" portion of the event notifications, does that still need to be done, or did other changes to the PoX events solve that issue?

I think the new PoX-2 contract events do include the data needed, although I haven't yet looked into using it for the stack-stx bitcoin op parsing code. Let me give that a try and get back to you.

EDIT: yep, the stack-stx bitcoin-op can now be correctly parsed with the new pox-2 events hirosystems/stacks-blockchain-api#1533

Copy link
Member

@jcnelson jcnelson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add some unit tests to each of the burnchain ops to verify that the JSON representation is accurate (i.e. conforms to the desired schema)? That's basically the only thing standing in the way of my approval right now.

@jcnelson
Copy link
Member

Also, can you rebase this on develop? That's where 2.1 lives now.

jcnelson
jcnelson previously approved these changes Jan 31, 2023
Copy link
Member

@jcnelson jcnelson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM; just need two things to be done before merging:

@CLAassistant
Copy link

CLAassistant commented Jan 31, 2023

CLA assistant check
All committers have signed the CLA.

@pavitthrap pavitthrap changed the base branch from next to develop January 31, 2023 22:01
@pavitthrap pavitthrap dismissed jcnelson’s stale review January 31, 2023 22:01

The base branch was changed.

@pavitthrap pavitthrap requested a review from jcnelson February 2, 2023 03:40
Copy link
Member

@jcnelson jcnelson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Just a minor code factoring nit about putting serialize/deserialize decorator methods into a common file in stacks-common.

Copy link
Contributor

@kantai kantai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes look good to me, but I think @zone117x and @jcnelson's comments should addressed. These changes impact the sortitiondb and burndb serialization and deserialization; I think this is fine, though, because 2.1 is already modifying these schemas enough that nodes need to sync from genesis anyways.

However, it does look like the serialization and deserialization changes broke some of the stack-stx tests, so it seems like something there needs to be fixed.

@@ -92,6 +94,49 @@ pub enum PoxAddress {
Addr32(bool, PoxAddressType32, [u8; 32]),
}

/// Serializes a PoxAddress as a B58 check encoded address or a bech32 address
pub fn pox_addr_b58_serialize<S: Serializer>(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These methods don't preserve the AddressHashMode, which makes them unsuitable for use within the sortition DB.

I think you have two options:

  • You can update the serializers for PoxAddress so that the relevant metadata is preserved, or
  • You can create a JSON-specific serialization method that will be used for the event stream.

I'm more in favor of the latter since, selfishly, I'm in the process of using already-spun-up nodes for testing and don't want to have to sync from genesis again, but that's something I can work around on my end. Up to you how you want to proceed. If you take the latter, please document it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just implemented the latter!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added docs for the serialization in the event dispatcher doc already.

Copy link
Contributor

@kantai kantai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

@blockstack-devops
Copy link
Contributor

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@stacks-network stacks-network locked as resolved and limited conversation to collaborators Nov 14, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants