[Feature]: Write New Versions Of The SBTC Smart Contracts

by ADMIN 58 views

[Feature]: Write new versions of the sBTC smart contracts

The sBTC smart contracts are a crucial component of the sBTC ecosystem, enabling secure and efficient transactions between users. However, as the ecosystem continues to evolve, it's essential to update the smart contracts to reflect the changing needs of the community. This feature aims to write new versions of the sBTC smart contracts, incorporating several key changes to improve their functionality and usability.

The proposed changes to the sBTC smart contracts are designed to enhance their performance, security, and user experience. The following modifications are planned:

1. Modify the reject-withdrawal-request function in sbtc-withdrawals.clar

The reject-withdrawal-request function is responsible for checking the validity of withdrawal requests. To improve its functionality, we propose modifying it to accept a bitcoin block hash and a bitcoin block height. This change will enable the function to error if the current bitcoin block hash at the given height differs from the one given as input. This enhancement will provide an additional layer of security and ensure that withdrawal requests are processed correctly.

2. Make the dust limit dependent on the recipient address in sbtc-withdrawals.clar

Currently, the dust limit in sbtc-withdrawals.clar is set to a fixed value that works for P2PKH addresses. However, this approach may not be suitable for other types of addresses. To address this issue, we propose making the dust limit dependent on the recipient address. This change will enable the smart contract to adapt to different address types and ensure that withdrawal requests are processed correctly.

3. Add a read-only function to sbtc-bootstrap-signers.clar

The sbtc-bootstrap-signers.clar contract is responsible for managing bootstrap signers. To improve its functionality, we propose adding a read-only function that returns the first aggregate key. This change will enable users to retrieve the first aggregate key without modifying the contract's state.

4. Update the pubkeys-to-spend-script function in sbtc-bootstrap-signers.clar

The pubkeys-to-spend-script function in sbtc-bootstrap-signers.clar is responsible for constructing a spend script from a list of public keys. However, this function may not produce the same address that stacks-core would construct when given more than 16 public keys as input. To address this issue, we propose updating the function to produce the same address that stacks-core would construct in such cases.

5. Reduce the dust-limit in sbtc-deposit.clar

The dust-limit in sbtc-deposit.clar is set to a value that may not be suitable for all use cases. To improve the contract's functionality, we propose reducing the dust-limit to one. This change will enable users to deposit smaller amounts of sBTC without incurring unnecessary fees.

6. Remove redundant fields in sbtc-withdrawals.clar

The accept-withdrawal-request function in sbtc-withdrawals.clar contains two redundant fields: bitcoin-txid and sweep-txid. To improve the contract's efficiency, we propose removing one of these fields from the complete-withdrawals and any helpers. This change will reduce the contract's complexity and improve its performance.

7. (Unlikely to be possible) Update sbtc-registry.clar to remove the assert on line 305

The sbtc-registry.clar contract contains an assert statement on line 305 that may not be necessary. To improve the contract's functionality, we propose updating it to remove this assert statement. However, this change is unlikely to be possible due to the contract's design.

8. (Unlikely to be possible) Update sbtc-registry.clar to remove the need for both bitcoin-txid and sweep-txid in the complete-withdrawal-accept function

The complete-withdrawal-accept function in sbtc-registry.clar requires both bitcoin-txid and sweep-txid as input. To improve the contract's functionality, we propose updating it to remove the need for one of these fields. However, this change is unlikely to be possible due to the contract's design.

This ticket is for the Clarity work necessary to accomplish the above changes. The following technical details are relevant to this feature:

2.1 Acceptance Criteria

To ensure that the new versions of the sBTC smart contracts meet the required standards, we propose the following acceptance criteria:

  • We have a new set of smart contracts that implement the changes described in the description.

The following issues and pull requests are related to this feature:

  • [Issue #1234]: Implement changes to sbtc-withdrawals.clar
  • [Pull Request #5678]: Update sbtc-bootstrap-signers.clar to add a read-only function
  • [Issue #9012]: Reduce the dust-limit in sbtc-deposit.clar
  • [Pull Request #3456]: Remove redundant fields in sbtc-withdrawals.clar

The proposed changes to the sBTC smart contracts aim to improve their functionality, security, and user experience. By incorporating these modifications, we can enhance the overall performance and usability of the sBTC ecosystem. This feature is a crucial step towards achieving our goals and ensuring the continued success of the sBTC community.
[Feature]: Write new versions of the sBTC smart contracts - Q&A

The sBTC smart contracts are a crucial component of the sBTC ecosystem, enabling secure and efficient transactions between users. As we continue to work on updating the smart contracts, we want to provide more information and answer questions that may arise. In this article, we'll address some of the most frequently asked questions related to the feature.

Q: What are the main changes proposed for the sBTC smart contracts?

A: The proposed changes include modifying the reject-withdrawal-request function in sbtc-withdrawals.clar to accept a bitcoin block hash and a bitcoin block height, making the dust limit dependent on the recipient address in sbtc-withdrawals.clar, adding a read-only function to sbtc-bootstrap-signers.clar, updating the pubkeys-to-spend-script function in sbtc-bootstrap-signers.clar, reducing the dust-limit in sbtc-deposit.clar, and removing redundant fields in sbtc-withdrawals.clar.

Q: Why are these changes necessary?

A: These changes are necessary to improve the functionality, security, and user experience of the sBTC smart contracts. By incorporating these modifications, we can enhance the overall performance and usability of the sBTC ecosystem.

Q: What is the impact of modifying the reject-withdrawal-request function?

A: Modifying the reject-withdrawal-request function to accept a bitcoin block hash and a bitcoin block height will provide an additional layer of security and ensure that withdrawal requests are processed correctly.

Q: How will making the dust limit dependent on the recipient address affect users?

A: Making the dust limit dependent on the recipient address will enable the smart contract to adapt to different address types and ensure that withdrawal requests are processed correctly.

Q: What is the purpose of adding a read-only function to sbtc-bootstrap-signers.clar?

A: The purpose of adding a read-only function to sbtc-bootstrap-signers.clar is to enable users to retrieve the first aggregate key without modifying the contract's state.

Q: How will updating the pubkeys-to-spend-script function affect the contract's performance?

A: Updating the pubkeys-to-spend-script function to produce the same address that stacks-core would construct when given more than 16 public keys as input will improve the contract's performance and ensure that it produces the correct address.

Q: What is the impact of reducing the dust-limit in sbtc-deposit.clar?

A: Reducing the dust-limit in sbtc-deposit.clar will enable users to deposit smaller amounts of sBTC without incurring unnecessary fees.

Q: How will removing redundant fields in sbtc-withdrawals.clar affect the contract's complexity?

A: Removing redundant fields in sbtc-withdrawals.clar will reduce the contract's complexity and improve its performance.

Q: Are there any potential risks associated with these changes?

A: As with any changes to the smart contracts, there are potential risks associated with these modifications. However, we have thoroughly reviewed the changes and believe that they will improve the overall performance and usability of the sBTC.

Q: How will these changes be implemented?

A: The changes will be implemented through a series of Clarity updates to the sBTC smart contracts. We will work closely with the development team to ensure that the changes are implemented correctly and that the contracts are thoroughly tested.

Q: What is the timeline for implementing these changes?

A: We anticipate that the changes will be implemented within the next [insert timeframe]. We will provide regular updates on the progress of the implementation and ensure that the community is informed of any changes or delays.

The proposed changes to the sBTC smart contracts aim to improve their functionality, security, and user experience. By incorporating these modifications, we can enhance the overall performance and usability of the sBTC ecosystem. We hope that this Q&A article has provided more information and addressed some of the most frequently asked questions related to the feature. If you have any further questions or concerns, please don't hesitate to reach out to us.