sBTC Research - Revealer API service

[8marz8]

Summary

This discussion aims to define the role of the "Revealer API service" and clarify whether, from a design perspective, we'd like to have this as a separate component/service or whether its functionality can/should be handled by an already existing component (like the signers).

Background:

The need for a two-phase commit-reveal scheme for sBTC transactions arose to accommodate users to peg-in their BTC from custodial wallets. In the designs and documents that followed this decision, the "Revealer" component acts as an intermediary service for its API to be called by external user-facing applications (I am assuming whatever this "sBTC bridge" is) to accept deposit requests) and for stackers/signers to poll for pending addresses and tapscript data.
Question -> was this API only needed for deposit requests and not withdrawals? I am not seeing it being used in Withdrawal diagrams.

Pros and Cons

In a recent meeting to discuss sBTC, there was some uncertainty about the role and requirements of the Revealer API. Specifically, the question was raised whether we need the Revealer to be a separate component or if the signer can fulfill its role, at least for sBTC v1.
If this whole commit-reveal scheme is relevant to the sBTC V1 release, I personally think having a separate intermediary service to act as a proxy between user-facing requests and the signer/stacker roles is useful...some reasons being:

• Allowing for independent updates/modifications of this service
• Currently, the signers for Nakamoto are more consumers of events/APIs...but making the signer to expose an API for application-facing deposit/withdrawal requests changes this, in addition to bloating the signers with more responsibility

References:

• https://stacks-network.github.io/sbtc-docs/sbtc-operations/commit-reveal-system.html
• https://docs.google.com/document/d/12HYjIZoBptrhpgqM_ezJjOk1-PXEKVnKDXvwfxdY1yk/edit#heading=h.ajy4ix8b4u8t
• https://github.com/stacks-network/sbtc/discussions/345

[netrome]

was this API only needed for deposit requests and not withdrawals? I am not seeing it being used in Withdrawal diagrams.

I believe the current idea is to have withdrawals initiated as contract calls on Stacks, instead of being initiated by Bitcoin transactions as in the original design. This greatly simplifies the withdrawal flow to essentially:

(Happy path)

1. The sBTC holder calls a smart contract function, let's call it withdraw-request
2. The Signers transfer the corresponding amount of BTC to the designated address in the request.
   (We might want to add some sort of withdraw-fulfill function to prove on Stacks that the withdrawal was accepted, though this might be implicit by the fact that the address received the designated amount as well)

This eliminates the need of any "commit-reveal" functionality for withdrawals - so only deposits require communicating with Signers over an API.

[AshtonStephens]

Is this suggesting that everything needs to go through clarity always?

[netrome]

Nope, only withdrawals. (Also more of a summary of how I interpret the current flow rather than a suggestion)

[8marz8]

I think to further progress on this topic, we first need to decide on our withdrawal/deposit flows, which are tied back to our MVP requirements.
More specifically, this is tied to the following point:
"Deposits and Withdrawals can be initiated from either the burnchain or the stacks blockchain"

The decision around whether to support requests from burnchain in addition to direct STX transactions/sBTC contract calls can scope the role of the Revealer API for handling the deposit flow (it can be called something else as well - "Signer API" was brought up).

[8marz8]

To conclude this discussion, can we assume the following?

• For sBTC V1, we want to proceed with an API-only approach for accepting deposits
• To not confuse it with previous commit-reveal discussions, we call this the "Signer API"
• The implementation of this API will be part of the signer binary and not a separate binary/instance

[netrome]

I agree with the two first point. I think we can leave the implementation open for a low-level-design issue. I don't think we want to assume that signers are exposing public endpoints.

[AshtonStephens]

Two solutions:

1. Having a hosted service maintained by a non-consensus party
2. Having the ability to register a Signer API on the Stacks chain