RSK Documentation
7' to read | Edit |
Share
|

RSK Documentation

RSK Community Call, December 2021 - Summary

RSK Community Call - December 2021

About the next hard fork HOP & RSKj Iris v3.2.0, Simplified Emergency Time-locks Refresh, Bridge peg-out Batching..

On 16th December 2021, The RSK Ecosystem held its fifth community call. The aim of these community calls is to discuss the RSK Improvement Proposals - RSKIPs, get the community involved, gather feedback, discuss the RSK consensus protocol, the formal process for proposing improvements, and the upcoming network upgrades. For more info, read the RSKIP Purpose and Guidelines.

Watch the Replay

It was live-streamed on several platforms, thanks to everyone who joined the Livestream! For those of you who missed out on attending it live, visit the links below;

🎥 Watch the RSK Community Call December 2021 on Youtube (Replay).

🗣️ Propose your own RSKIPs

🔗 Join the RSK Research & Innovation Forum

🗣️ Suggest RSKIPs to discuss in the next community call

🔗Join our Open Slack Community and ask your questions in #research-and-innovation.

The speakers on this call were:

  • Adrian Eidelman
  • Sergio Demian Lerner
  • Marcos Irisarri
  • Brendan Graetz

In this call, we discussed:

The RSKj IRIS v3.2.0

Adrian Eidelman gave brief updates on the next release of RSKj. He said the IRIS v3.2.0 will happen in early January 2022. The new version will contain several improvements to the JSON-RPC interface (e.g, the pending argument for getBlockByNumber), improved gas estimation, support for new methods specifically support for new arguments that were not supported in already existing methods for. Also, there will be various performance improvements.

He pointed out that all these changes are non-consensus changes, so this release is not a mandatory upgrade for RSK Mainnet. There are improvements being made to adjust the minimum difficulty for users and developers working on RSK Testnet. This does constitute a consensus change only for the RSK Testnet. Thus v3.2.0 of RSKj will be a mandatory upgrade for RSK Testnet.

See related links:

The next hardfork: HOP

Adrian Eidelman also talked about the next hardfork named HOP, though the date for this hardfork has not been set yet, he said this is open for discussion, and anyone can post their proposals to be discussed and included in the next hardfork via the RSKIP 291: Network Upgrade HOP Initial Proposal.

He said two improvements were proposed which are Peg-out Batching and Simplified Emergency Time-locks Refresh. Read more about these proposals in Network Upgrade RSKIP. These same proposals were subsequently discussed in more detail.

Simplified Emergency Time-locks Refresh

Simplified Emergency Time-locks Refresh

Sergio Lerner talked about the Simplified Emergency Time-locks Refresh, he started with a brief recap of the history of what is now the RSK PowPeg, the potential problems with the PowHSM and the solutions introduced by RSKIP-201. He talked about the activation of the emergency multisig and that it has been ready since the IRIS network upgrade proposed in Jan, 2021 and activated in Aug, 2021 but it only activates after the first change in the powpeg members and that we have delayed activation because there was no automatic method to refresh the UTXOs (only manual refresh) and that the RSKIP-264 (Simplified Emergency Time-locks Refresh) proposes such a method. The Emergency multisig will be activated with a PowPeg renewal immediately after RSKIP-264 is activated.

He highlighted the features of RSKIP-264:

  • Checks all UTXOs for timelock expiration every 2 weeks
  • Renews the time-locks 6 months prior to the expiration
  • Compete renewal of all UTXOs every 6months
  • Low expected average load
  • Best efficiency if RSKIP-270 (Bridge UTXO set size management) is activated

See related links;

RSKIP 271 - Bridge peg-out Batching

Marcos Irisarri talked about the bridge peg-out batching. He said the idea is to reduce the cost for users when performing peg-out transactions while maintaining security of the peg.

He talked about the current peg-out process;

  1. RSK user sends n RBTC to the Bridge contract address
  2. Bridge smart contract creates a BTC transaction sending n BTC to the user’s derived BTC address
  3. Wait 4000 RSK blocks confirmations (33 hours approx) then the PowHSM signs the transaction
  4. User receives the amount sent to the Bridge minus the BTC transaction fees

The proposal is to;

  1. Each time a user sends RBTC to the Bridge, the peg-out request is added to a queue
  2. Every 360 RSK blocks (approximately 3 hours) the Bridge creates one BTC transaction with an output for each of the peg-out requests in the queue
  3. Wait 4000 RSK blocks confirmations (33 hours approx) then the PowHSM signs the transaction
  4. Each user receives the amount sent to the Bridge minus a fraction of the BTC transaction fees

He also highlighted the pros of the bridge peg-out batching, which includes less fees to be paid by users (total fee is divided among all the users receiving funds), and the pros involved. These include additional waiting time for the user to receive the funds (9% increase). This time has the potential to be reduced to 16 hours approximately in a following network upgrade.

See related links;

Decisions

No decisions were made during the December Community Call.

However, there was a short debate about RSKIP-271:

  • Brendan raised the question about whether both RSKIP-271 and the RSKIP that would halve the waiting time could be both included in HOP, or whether the latter needed to be in a separate network upgrade.
  • Sergio raised the question about whether RSKIP-271 could be implemented without necessitating a network upgrade in the first place, by avoiding consensus changes.
  • These questions were not resolved during the call, and thus the discussion continues in the RSK Research forums

Summary

For more details on these, please watch the recording on Youtube. Want to champion an RSKIP? Missed the previous RSK Community Call? Watch the recording on Youtube. Also, leave a comment on this thread for the next community call!

Resources

Thanks for reading!