Cross-Chain BFT Consensus

BFT is a cross-chain consensus mechanism based on Store Groups, Shamir polynomials, and the composition of one-time TSS (Threshold Signature Scheme) signatures per each round. It is utilized by Kaon in a cross-chain context and is managed by the chain’s dPoS.

  1. User Interaction:

    • The user calls a view function send on the Kaon contract to obtain an address for the P2WSH (Pay-to-Witness-Script-Hash) or P2TR (Pay-To-Taproot) lock script on the Bitcoin Network from the current round of sMPC.

    • This contract also provides the current fee for transfer-type transactions.

  2. Locking BTC:

    • The user locks BTC using the retrieved address.

    • The Bitcoin node processes the signature of the output from the UTXO (Unspent Transaction Output) transaction sent by the user.

  3. Collator Nodes Processing:

    • Collator Nodes, part of the Bitcoin Network, will also process this signature.

    • If they identify a valid signature, the Transaction Handler on the Kaon side of the node will be triggered.

  4. Fee Deduction and Distribution:

    • The fee for the transfer will be deducted from the base transaction value.

    • If the fee is insufficient, the transaction will be ignored until the user sends an additional amount of BTC.

    • The fee will be distributed among the validators who processed the current sMPC round.

  5. Updating Lock Manager:

    • The received output will be added to the Lock Manager, which will update its lock script according to sMPC round updates.

  6. Minting mirrorBTC:

    • Based on the transaction sender, mirrorBTC (with the fee deducted) will be produced on the Kaon Network, with the sender as the owner.

    • (EVM chains only) A special token voucher, similar to an NFT, will be issued to the sender as an identifier of the token.

Managing Lock Script

  • At the end of the sMPC round, the Lock Manager may produce an updated P2WSH or P2TR lock script for some of the locked outputs.

Reversing the Process (Returning BTC to the Bitcoin Network):

  1. User Initiation:

    • The user sends their mirrorBTCs to the contract.

  2. Validation:

    • Recognition and validation processes are initiated.

    • (EVM chains only) If successful, the voucher and mirrorBTC will be destroyed.

  3. BTC Transaction Composition:

    • On the Bitcoin node side, a P2WSH or P2TR type transaction will be composed and signed, with the user as the receiver.

  4. BTC Retrieval:

    • The user can retrieve their locked BTC, completing the reversal process.

Stake Transaction in Bitcoin Network

The BTC staker gain the ability to validate Kaon’s transactions on the Bitcoin network by creating a staking transaction. This is a Bitcoin transaction that commits a specific amount of BTC to be staked using Kaon-recognized Bitcoin staking scripts. These scripts lock the stake for a chosen period of time and enable Kaon Consensus Layer to be effective part of the Staker's operational logic.

Slashing is possible due to the internal structure of the staking transaction on the Bitcoin side.

Requirements for a valid staking transaction:

  • Must use SIGHASH_ALL.

  • Note: In the future, we plan to adopt the SINGLE | ANYONECANPAY approach to combine transactions and reduce fees.

  • Note: For continuous loops, ALL | ANYONECANPAY is used.

  • Can contain more than one input.

  • Can contain one or more outputs. One of these outputs must be a Taproot output committing to the BTC staking scripts recognised by Kaon, henceforth known as the Staking Output.

The staking output is a Taproot output that can only be spent through a script spending path. The key spending path is disabled by utilising the “Nothing Up My Sleeve” (NUMS) point as the internal key. The chosen point is the one described in BIP341, specifically:

H = lift_x(0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0)

This represents an impossible key that cannot be used due to mathematical limitations. It has been proven that this internal key does not have a known solution for the Taproot signature, effectively making it impossible to spend via the key path.

The staking output can be spent through four script spending paths.

1. Recognition Path (Non-spendable | Technical)

<LABEL_VERSION:2> OP_NUMBER 
<LABEL:KAON> OP_DATA ESCAPE_CODE 
<Commitment:STAKE> OP_DATA 
<Descriptor:SCRIPTSIG> OP_DATA 
<AUX_Signer:SELF> OP_DATA

Where:

  • <LABEL_VERSION> is the version of the protocol (currently set to 2).

  • <LABEL> is the name of the protocol (KAON).

  • ESCAPE_CODE is a code used to terminate the current path processing in Bitcoin Core.

  • <Commitment> represents the stake that will be mirrored on Kaon, and should therefore include a pledge commitment.

  • <Descriptor> is predefined as the scriptsig processor.

  • <AUX_Signer> is predefined as SELF, indicating to Kaon to produce a stake transaction on the Consensus Layer with the sender acting as the staker.

Notes:

  • The stake transaction has a strict structure following the ESCAPE_CODE.

  • The ESCAPE_CODE is not intended to be any of the OP_SUCCESSx opcodes, as using these would compromise the security of a soft fork and is thus not recommended. Additionally, OP_RETURN is not available within a Taproot script. Various implementations are being explored for a PoC, and the final design will be presented upon completion of testing.

  • The mirrored stake will facilitate the determination of groups of validators and witnesses for the current stake signature in forthcoming epochs.

2. Degrading Epoch Renew Keep Alive

This branch enables the TSS sMPC Validator Group to transfer BTC, provided it has been approved by the TSS sMPC Witness Group.

<StakerPk> OP_CHECKSIGVERIFY
<VALIDATOR_GROUP> OP_CHECKSIGVERIFY
<WITNESS_GROUP> OP_CHECKSIG
1 OP_CHECKSEQUENCEVERIFY

Where:

  • <StakerPk> is the BTC staker’s public key.

  • <VALIDATOR_GROUP> is the MuSig2 TSS-based key for the related Validators sMPC group (partial session through the Consensus Layer, nonces are calculated according to BFT).

  • <WITNESS_GROUP> is the MuSig2 TSS-based key for the related Witness sMPC group. It becomes enabled only after the VALIDATOR_GROUP signature; it cannot spend but can only confirm.

Note: Using MuSig2 allows the protocol to configure and support a flexible number of required signatures.

Future Work: Validate the compatibility of MuSig2 and TSS; we may need to consider utilising FROST.

Additional Combinations Within a Path

This script incorporates several sub-routes:

a) Degrading in 6 Hours

After 6 hours, a failsafe sub-route becomes available. This timelock allows the BTC to be returned to the sender if the script used is outdated and remains unused.

<StakerPk> OP_CHECKSIGVERIFY
360 OP_CHECKSEQUENCEVERIFY

At this point, a Validator and Witness groups signatures are no longer required.

b) Degrading in 50 Minutes

<StakerPk> OP_CHECKSIGVERIFY
<WITNESS_GROUP> OP_CHECKSIGVERIFY
5 OP_CHECKSEQUENCEVERIFY

After 50 minutes, a failsafe sub-route becomes available. This timelock enables the BTC to be returned to the sender if the address used is outdated and remains unused.

c) Mark as Corrupted

This sub-route allows for the immediate execution of an emergency procedure without any delays, effectively marking the staking output as corrupted.

<VALIDATOR_GROUP> OP_CHECKSIGVERIFY
<WITNESS_GROUP> OP_CHECKSIG
<Preimage_Announce_Corrupted>

Where:

  • <VALIDATOR_GROUP> is the MuSig2 TSS-based key for the related Validators sMPC group.

  • <WITNESS_GROUP> is the MuSig2 TSS-based key for the related Witness sMPC group.

  • <Preimage_Announce_Corrupted> is a preimage of a transaction that signals the corrupted state.

In this sub-route, the Validators group provides a signature verified by OP_CHECKSIGVERIFY, ensuring that only authorised validators can initiate this path. The Witness group then provides their signature, verified by OP_CHECKSIG. The inclusion of <Preimage_Announce_Corrupted> allows for an immediate action without any time delays or timelocks. This mechanism is crucial for situations where the staking output needs to be invalidated or revoked promptly due to security concerns or detected anomalies within the related spending output script. By marking the stake as corrupted, it triggers an emergency protocol that safeguards the system from potential threats.

Future Work: Extend the applicable timeframe for preimaged transactions to enhance flexibility and security. It is a PoC version of the protocol. It is possible that this path will be merged with a Slashing path later.

d) Proposed by Peer (Wake-Up)

This sub-route enables a peer to propose a transaction, effectively acting as a wake-up mechanism to re-engage or update the staking process.

<VALIDATOR_GROUP> OP_CHECKSIGVERIFY
<WITNESS_GROUP> OP_CHECKSIGVERIFY
<StakerPk> OP_CHECKSIG
1 OP_CHECKSEQUENCEVERIFY

Where:

  • <VALIDATOR_GROUP> is the MuSig2 TSS-based key for the Validators sMPC group.

  • <WITNESS_GROUP> is the MuSig2 TSS-based key for the Witness sMPC group.

  • <StakerPk> is the BTC staker’s public key.

In this sub-route, both the Validators and Witness groups provide their signatures, each verified by OP_CHECKSIGVERIFY, ensuring consensus and coordination between these groups. The staker then provides their own signature, verified by OP_CHECKSIG. The inclusion of 1 OP_CHECKSEQUENCEVERIFY introduces a minimal timelock of one block, ensuring that the transaction cannot be included in the blockchain until after this delay.

This path is particularly useful when a peer (the staker) wishes to update or renew the staking output or when an external prompt is needed to re-engage the network’s staking activities. It acts as a ‘wake-up’ call, allowing the staker to initiate actions that require collective agreement from both the Validators and Witness groups, thereby maintaining the security and integrity of the network through mutual consent.

3. Slashing

The slashing path is utilised to penalise sMPC participants and stakers in cases where they act maliciously or violate protocol rules. It commits to a script that serves as a gateway for a pre-signed transaction to transfer BTC to an existing parallel TSS sMPC Validator Group. This transaction can only be executed if the TSS sMPC Witness Group signs the Taproot branch designated for rejection.

<StakerPk> OP_CHECKSIGVERIFY
<VALIDATOR_GROUP> OP_CHECKSIGVERIFY
<WITNESS_GROUP> OP_CHECKSIG
1 OP_CHECKSEQUENCEVERIFY

Where:

  1. Activation of Stake: For the stake to become active, the staker must publish a pre-signed slashing transaction using a mirror script.

  2. Validation by Groups: The <VALIDATOR_GROUP> and <WITNESS_GROUP> validate this transaction and publish their own signatures.

  3. Consensus Layer Signature: The only signature missing to send the slashing transaction is the MuSig2 signature from the currently active validators in the Kaon's Consensus Layer.

  4. Execution of Slashing: If they decide to slash an operator, they sign this mirrored transaction, which is then mirrored back to the Bitcoin network, executing the slashing event.

Note: There is no emergency path for the stake transaction output.

Additional Clarifications

To provide a clearer understanding, consider the following elaboration:

  1. Mirroring Process:

  • A BTC staker creates a staking transaction on the Bitcoin network.

  • This stake is mirrored into the Kaon Consensus Layer.

  • The staker must also lock Kaon tokens for the mirrored stake to be effective.

  1. Emergency Cases:

  • In an emergency, the Consensus validators provide the final signature required for the pre-signed emergency transaction used to activate the stake.

  • They sign this transaction on the Consensus Layer without the need for a Bitcoin node.

  • The transaction is then mirrored back to the Bitcoin network, completing the slashing event.

Implications

  • Direct Control Over Slashing: Our Consensus Layer directly manages slashing on the Bitcoin network in a straightforward manner.

  • Non-Custodial Trust: We achieve a level of non-custodial trust comparable to simple timelock script but in a more advanced manner.

PreviousKaon Chain Consensus (dPoS)NextSlashing Incidence Process

Last updated