-
Notifications
You must be signed in to change notification settings - Fork 685
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
Conversation
27a6f34
to
8f1e5d6
Compare
Codecov Report
@@ 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
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
@zone117x -- in the issue #2591, you mentioned that the API needs more information from events for things like the |
I think the new PoX-2 contract events do include the data needed, although I haven't yet looked into using it for the EDIT: yep, the |
There was a problem hiding this 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.
Also, can you rebase this on |
There was a problem hiding this 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:
- This needs to be based on
develop
, notnext
. - This should extend @kantai's work on sBTC: Add burn ops RPC for PegIn #3511 to use the Rust-idiomatic way of serializing burnchain operations to strings.
1a39f3f
to
3893a52
Compare
3893a52
to
f36473a
Compare
There was a problem hiding this 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
.
There was a problem hiding this 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.
src/chainstate/stacks/address.rs
Outdated
@@ -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>( |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just implemented the latter!
There was a problem hiding this comment.
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.
There was a problem hiding this 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!
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. |
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 withSome
, then when deserializing, it is set toNone
. 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 withimpl_array_hexstring_fmt
, and moveto_hex
andfrom_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
docs/rpc/openapi.yaml
andrpc-endpoints.md
for v2 endpoints,event-dispatcher.md
for new events)clarity-benchmarking
repobitcoin-tests.yml