API support for Subnets

[saralab]

Is your feature request related to a problem? Please describe. Describe the solution you'd like

• Hyperchains emits new Deposit and Withdrawal events that need added API support
• We are currently disabling the API for hyperchains testing via clarinet integrate, which is otherwise causing a deadlock.

@pavitthrap can add more context to this.

[saralab]

Matt:

• Setting up Event Handlers(empty to start with) for the new Events, so the API doesn't crash at the least
• Then Update the Event Handlers to handle the events : Requires further discussion and thinking. Ex: pointing to the right burnchain [ Stacks instead of Bitcoin]

[zone117x]

@pavitthrap @janniks and I discussed this a bit recently. @pavitthrap could you give a bit of context around which events need to be consumed (as opposed to dropped) in order to ensure account balances on hyperchains are accurate? For example, I think you mentioned withdrawals explicitly -- I'm curious if the hyperchain node would just emit regular "STX/FT/NFT" transfer events which would make the account balances in the API accurate regardless of the new hyperchain-specific events.

[zone117x]

@pavitthrap for an initial pass with getting the API to at least boot & run with a hyperchains node, could you list the new events POST endpoints that were added, or link me to any docs/code for them?

[kantai]

The only difference in the events POST schema are the new withdrawal events (which are just possible entries in the events field of the new block and new microblock POSTs.

Those look like:

           {
                "txid": string,
                "event_index": number,
                "committed": bool,
                "type": "stx_withdraw_event",
                "stx_withdraw_event":  { 
                       "sender": string,
                       "amount": number,
                      "withdrawal_id": number
                }
            }

           {
                "txid": string,
                "event_index": number,
                "committed": bool,
                "type": "ft_withdraw_event",
                "ft_withdraw_event":  { 
                       "asset_identifier": string,
                       "sender": string,
                       "amount": number,
                      "withdrawal_id": number,
                }
            }

           {
                "txid": string,
                "event_index": number,
                "committed": bool,
                "type": "nft_withdraw_event",
                "nft_withdraw_event":  { 
                       "asset_identifier": string,
                       "sender": string,
                       "id": number,
                      "withdrawal_id": number,
                }
            }

[kantai]

I think the easiest way to test out the changes is to try to start a "hyperchain API" using the clarinet integrate setup. It will try to spin up an API instance listening to a hyperchain miner. I think it fails before there's ever a withdraw event: I remember there being something like a "bitcoin parsing" failure -- probably because the "burnchain" referenced by the hyperchain node's events is actually Stacks, not Bitcoin.

[zone117x]

Awesome, thanks @kantai! Is this guide a good way to get clarinet + hyperchains setup? https://github.com/hirosystems/stacks-hyperchains/blob/master/NFT_USE_CASE.md

[kantai]

Yep, that will work.

[rafaelcr]

Blocked by https://github.com/hirosystems/stacks-subnets/issues/160

[zone117x]

API support for subnets is currently in beta deployment, and living in the subnets branch. The latest release with subnets support is v7.1.0-beta.2.

We're waiting until we have a stable subnet deployment running in testnet before merging into main branch and cutting a full release, that way we avoid repeated API stable version bumps while we make any tweaks & bug fixes that may be necessary.

[zone117x]

Subnet support is included in the latest stable release.