Rootstock (RSK)’s Peg-out efficiency improvement — Segwit (part 1/3)
Co-authors: Ramsès Fernàndez-València and Nicolás Vescovo
This analysis presents a proposal for the reduction of the peg-out cost and it would also allow increasing the number of pegnatories without increasing the peg-out cost based on the use of Segwit in RSK’s PEG, including a modified digital signature scheme. It also analyzes the feasibility and the effort needed to implement either a threshold or a multi-signature scheme.
In this post, I describe the main actors of the architecture, namely: the bridge, the pegnatories, and the HSM. I also introduce the limitations of the current design, in terms of cost and scalability, and provide a brief introduction to Segwit versions.
In the next post, I will describe the proposals studied: Segwit v0 and Segwit v1/Taproot (FROST, ICE-FROST and MuSig2). And I will also explain the modifications required by each scheme to be implemented successfully.
Finally, in the last post, I will end up with a comparison of the proposals and a conclusion.
No more waiting, let’s start introducing the actors of the current RSK architecture.
Actors
Bridge and 2 Way Peg
A bridge is a mechanism to transfer value across blockchains by locking assets on one side and unlocking (equivalent value) on the other. In RSK, this is implemented by the Bridge Contract.
The Bridge Contract is an unstoppable pre-compiled smart contract living in the RSK blockchain. The role of the Bridge Contract is to maintain an up-to-date view of the Bitcoin blockchain, verify peg-in requests and command peg-outs. To accomplish this functionality, the Bridge contract manages a Bitcoin wallet in SPV (Simple Payment Verification) mode. In this mode, transactions are confirmed by block headers and block headers are minimally validated, but the validation includes the expected proof of work.
Technically, the RSK Powpeg is a hybrid peg. Performing a peg-in is as easy as sending the bitcoins to the Powpeg address and informing the Bridge Contract about the Bitcoin transaction. The Powpeg functionaries provide a “watchtower” service on behalf of users and inform the Bridge of any peg-in as well. Users can also inform the Bridge about peg-in transactions and Bitcoin block headers. To prevent intended or unintended invalid forks, the Bridge is designed to wait for 100 confirmations (on Bitcoin network) before confirming a peg-in transaction.
To perform peg-outs is not as simple as a peg-in. The Bridge accepts peg-out requests from RSK accounts, and after 4000 RSK block confirmations (approximately 200 Bitcoin blocks), the Bridge builds a Bitcoin peg-out transaction, and the pegnatories transmit the transaction to the PowHSM to sign this transaction. The Bridge selects the transaction inputs (or UTXOs) to include in the peg-out transactions, preventing selective censorship of UTXOs of any kind.
Pegnatories
A pegnatory is an autonomous functionary that protects the multi-signature of the Powpeg. The primary role of a pegnatory is to keep their PowHSM hardware and Powpeg node connected and alive at all times; pegnatories are involved in the signing of transactions indirectly as well as being data relays. To be clear, pegnatories do not participate in the production of blocks on the RSK blockchain. Pegnatories are incentivized to participate by receiving a small portion of RSK transaction fees that are automatically channeled to them. At present, RSK uses a 7/13 multisig. Thus, at any point, there are 13 Pegnatories each running a distinct Powpeg node with its unique PowHSM.
PowHSM
The PowHSM is specialized hardware connected to a special type of RSK full node (the “Powpeg Node”). A PowHSM is an external tamper-proof device that creates and protects one of the private keys required for the Bitcoin multi-signature protocol, only signing transactions proven valid by enough cumulative work. The Powpeg node is designed to have maximal connectivity and to communicate information about the RSK blockchain avoiding becoming isolated. The RSK Powpeg protects private keys stored in these special-purpose PowHSMs based on tamper-proof secure elements. Each PowHSM runs an RSK node in SPV mode, so signatures can only be commanded by a chain containing enough cumulative proof of work.
Users
The users of the bridge are merchants and exchanges or any individual user transferring value between the Bitcoin and RSK networks. Users interact with the RSK 2-way peg by sending and receiving peg-in and peg-out transactions to the Bridge smart contract through the Bitcoin and RSK networks.
The Limitations of the current RSK peg
The RSK peg uses multi-signatures to implement a threshold scheme that protects the locked bitcoins. Multi-signatures are simple and relatively efficient for small groups, but they become expensive as the number of signers increases. Each input signed in a peg-out transaction must transmit m-out-of-n signatures, and each signature consumes 65 bytes, and n public keys, consuming 33 or 65 bytes each, depending on if they are compressed or not. Threshold signatures, on the contrary, consume only 65 bytes for all signers, no matter their number.
ECDSA threshold signatures were possible even before the activation of Taproot in Bitcoin. However, this upgrade has enabled more signature schemes that are simpler, more secure and more efficient.
Segwit v0 / v1
Segwit v0 (Native)
Segwit stands for “segregated witness”, and it is an upgrade to the Bitcoin consensus rules and network protocol proposed and implemented as a BIP — 91 (https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki) soft-fork that was activated on Bitcoin’s main-net in 2017.
Before segwit’s introduction, every input in a transaction was followed by the witness data that unlocked it. The witness data was embedded in the transaction as part of each input. It is called segregated witness because it implies separating the signature or the unlocking script of a specific output. The witness data is moved outside the transaction.
In Segwit v0, the Block Size concept is replaced by Block Weight. Block Size is measured in Bytes and Block Weight is measured in Weight Units (WU). The maximum weight of a 1 MB block is 4000 WU. In calculating the weight of a transaction, a non-witness 1 byte weighs 4 WU and a witness byte weighs 1 WU.
Segwit Native addresses are also named “P2WSH”, which stands for Pay-To-Witness-Script-Hash.
Segwit v0 (Compatible)
This design allows older wallets and other software to send bitcoin to SegWit addresses even if they themselves do not support SegWit. The receiver of a SegWit compatible transaction can spend the bitcoin as a SegWit input, and thus save on fees.
Therefore, a P2WSH can be embedded in a P2SH address and is noted as P2SH-P2WSH. The sender’s wallet sees this as a P2SH address and can make payments to it without any knowledge of segwit. The receiver’s wallet can then spend this payment with a segwit transaction, taking full advantage of segwit and reducing transaction fees.
Segwit v1
Segwit v1 (aka Taproot) is an upgrade of the previously mentioned Segwit v0. It allows payments to Schnorr public keys that may optionally commit to a script that can be revealed at spend time.
Coins protected by taproot may be spent either by satisfying one of the committed scripts or by simply providing a signature that verifies against the public key (allowing the script to be kept private). Taproot is intended for use with Schnorr signatures that simplify multiparty construction (e.g. using Frost) and with MAST (e.g. using MuSig2) to allow committing to more than one script, any one of which may be used at spend time.
This soft fork was composed of three main BIPs:
- BIP-340: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki
- BIP-341: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
- BIP-342: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki
Segwit v1 addresses are also named “P2TR”, which stands for Pay-To-Taproot.
