Nomic - a bitcoin sidechain

Description of the technical bitcoin-peg structure

This article is a summary of a technical article describing the whole bitcoin-peg structure, written by Matt Bell: Proof of Stake Bitcoin Sidechains - bitcoin Peg.

Intro

Nomic is a bitcoin Proof of Stake sidechain based on the Tendermint consensus protocol. It aims to enable a faster circulation and application of bitcoin-pegged tokens, identified as nBTC, over a parallel network to the main bitcoin-timechain which can be exchanged for BTC in a 1:1 ratio.

Security of the PoS network is improved by periodically timestamping the Nomic-sidechain on the bitcoin-timechain: clients syncing to the network can always relay on Proof of Work security when verifying blocks’ consistency.

Taproot upgrade set up the ground for designing a bitcoin multisig contract for the bitcoin-bridge management, whose participants reflect a whole set of validators.

---

BTC Reserve management

A bitcoin-reserve is maintained through a bitcoin-multisig contract, where the signatories in control of the funds are all the validators of the sidechain.
Voting power of each validator is represented as a signature share in the multisig.

📌 Until the Taproot update it was impossible to realize a multisig in the bitcoin-network managing a number higher than 16 participants. With Taproot is now possible to manage a bitcoin multisig representing a whole set of validators (typically > 64). Also, bitcoin-scripts can be better detailed and managed with an overall diminished byte dimension.

• here an in depth analysis of the Taproot upgrade

Spending conditions for the funds in the reserve are enforced through a reserve script.

Reserve script

The script works as follows:

1. Base set signature → authorizes spending if a signature is produced aggregating signatures from a subset of validators representing over 2/3 of the total voting power. We call this subset the base set.

2. Fallback script → if condition 1. fails, spending is authorized through a weighted multisig containing all signatory public keys and voting power. We refer at this as the fallback script.

The base set signature is expected to be taken the vast majority of time, since empirically PoS validators have shown to have extremely high uptime. However, the network will fall back to the fallback script if:

• even a single partecipant of the base set is offline;

• after a timeout the base set has not completed its aggregated signature.

Considerations

• The more sophisticated structure of the fallback script comes with an higher bitcoin network fee, which can be imposed to be paid with the stake of the offline partecipants who caused the fallback script to be triggered.

• Since Taproot allows a multisig up to 1’000 partecipants, while PoS validators are typically 64-175, security can be leveraged allowing nodes that are not validators to participate as signatories.

---

Depositing BTC in the reserve

In order for depositors to move funds into the reserve, they have to send a bitcoin tx to the reserve script, which is modified in order to contain an extra script indicating where the pegged BTC should be credited in the sidechain (this deposit scheme is called Script Path Commitment Scheme). It’s up to depositors to indicate the desired destination address in the Nomic-sidechain.

⚠️ Detection of deposits by Relayer nodes The output of the above reserve script has a unique hash due to its unique commitment (it’s an hash obtained through a unique sidechain destination address), meaning that relayers could face difficulties to detect which bitcoin txs are correlated to the reserve script. To solve this issue, relayers will need to store the sidechain-destination-addresses received from depositors and match every Taproot output they see in bitcoin txs against all currently valid signatory sets and possible deposit commitment addresses.

Deposit finality

In order to avoid the risk of granting pegged nBTC on the Nomic-sidechain but then having the deposit-tx reverted on the bitcoin network (for any reason), the system has to consider a deposit final only after it has been confirmed sufficiently deep on the bitcoin-timechain. This is done by waiting for at least the equivalent time for the total pending deposit quantity to be mined.

For instance, if a total of 8 BTC is deposited and 6.25 BTC are mined per block on mainnet, then waiting for 2 confirmations is a safe depth, since a miner would likely have more costs in a chain reorg than the gains made from stealing the deposit.

The total BTC pending deposit quantity, is made up by the sum of all individual amounts currently being deposited. Individual deposits’ statuses move from ”pending” to ”final” in a FIFO order (first in, first out), where individual confirmation time is scaled in relation to the total confirmation time.

📌 Example 
Let’s assume:
- a total quantity of 12 BTC being deposited from 3 depositors, 3 BTC, 5 BTC and 4 BTC respectively in this order;
- block reward is 6,25 BTC.
Then 2 blocks’ confirmation are needed, almost 20 min. 1st deposit is confirmed after 5min ( 3/12*20 ), 2nd deposit’s confirmation follows after 8min &20sec (5/12*20) and the 3rd deposit gets confirmed after 20min.

Market speculation on deposits

Since the above approach is very conservative and user experience is degraded compared to traditional centralized platforms (which often only wait for 1 or 2 block confirmations), a market for speculation on tx-confirmation is created: a depositor may sell these unconfirmed-deposit tokens to traders who have beliefs about the deposit's likelihood to eventually be confirmed. Tokens will trade at a market price less than 1 nBTC.

Price depends on factors such as perceived risk, the time-value of money until the deposit is confirmed, and liquidity in the unconfirmed deposit market.

Deposit confirmation’s likelihood is evaluated through data such as the deposit's prevalence in BTC miners' mempools, whether the deposit opts into replace-by-fee, network hashrate conditions indicating likelihood of a reorg, knowledge about the depositor, etc.

Deposit reclamation & Unbonding period

Problem: It may happen that a deposit-tx takes a long time for confirmation such that it is made to an outdated reserve script (for ex. when there is an high load on the bitcoin network). The sidechain cannot honor such deposit, since signatories/validators are not necessarily available anymore or may have unbonded their stake. This would result in a loss of funds.

Solution:

• Deposit reclamation: enabling depositors to reclaim the funds after a given time or block height. This additional condition is implemented in the reserve script thanks to Taproot.

• Unbonding period: setting a sufficiently long unbonding period in the Nomic-sidechain (order of days).

Deposit reclamation

This timelock field needs to be set to a time/block-height sufficiently after the deposit-tx has been:

• confirmed by the bitcoin-network;

• relayed to the Nomic-sidechain;

• collected into a checkpoint (explained later in this article) & the checkpoint gets confirmed by the bitcoin-network.

As an extra assurance for reclaims, depositors may also presign a reclamation-tx and send it to “watchtower” nodes, who broadcast it on their behalf as soon as the timelock period passes.

Unbonding period

If a deposit-tx is sent, but the validator set slightly changes before confirmation, the deposit still has to be considered valid. In order to assure this, the unbonding period in the Nomic-sidechain has to be significantly longer then the deposit-tx processing time.

The same applies for deposit reclaims, granting that unbonding period is way longer than the reclamation period.

---

Minting BTC in the sidechain: nBTC

Once a relayer node detects a valid bitcoin deposit-tx, it will broadcast a deposit proof to the Nomic-sidechaincontaining:

• bytes of the tx data;

• bytes of the destination address in the sidechain;

• hash of the bitcoin block containing the tx;

• a merkle branch proving the tx was included in the block.

These elements are sufficient to guarantee the BTC-deposit event. After receveing the deposit proof, the sidechain will mint the pegged bitcoin nBTC and paid them to the destination address. nBTC can be transferred in the sidechain, used in smart contracts or be burned to trigger withdrawals from the reserve back to the bitcoin-network.

Bitcoin-Nomic mirroring: Checkpoints

Periodically the network will make certain txs on the bitcoin-timechain, called checkpoints, that serve the purpose of:

• collecting deposits and disbursing pending withdrawals;

• updating the reserve script to reflect the latest signatory set (that represent the validators’ voting power;

• giving light clients a tool to double-check the state coherence between the chains.

Deposits are collected together in a deposit collection-tx, while pending withdrawals are bundled together in the disbursal-tx that pays to various destination bitcoin-addresses.

A checkpoint-tx take into account both the deposit collection-tx and the disbursal-tx, tracking the evolution of the BTC reserve amount over all the checkpoints made. It has the following structure:

INPUTS:

• The reserve output of the previous checkpoint transaction.

• The deposit collection-tx output (if there have been deposits) .

OUTPUTS:

• The reserve output, equal to the amount of bitcoin which are to be held in reserve. It’s paid to the updated reserve script based on the most recent signatory set.

• The disbursal-tx output, equal to the total amount of bitcoin to be disbursed (If there are pending withdrawals) . Paid to the updated reserve script based on the most recent signatory set.

Checkpoint Interval

A checkpoint should be created every time the signatory set changes, or on a certain interval. It’s feasible for the network to produce the ideal of one checkpoint per bitcoin block.

Preventing PoS long-range Attack

A known issue of proof-of-stake networks is the so called long-range-attack, where a validator tries to fork the chain from a sufficiently long ago created common block, such that its staked-capital has already been returned. In this way, he can reproduce an alternative chain with no risk to be punished by having its stake burned, and trick clients syncing to the their “fake”-network.

Bitcoin checkpointing allow clients to prevents long range attacks by following a chain of checkpoints:

1. the client first ensures that the bitcoin blocks header are on the highest-work chain;

2. with the checkpoint-tx and its merkle branch, he can prove that it is included in the bitcoin block;

3. the client can verify the coherence of the link between a checkpoint and its previous one.

---

Relayers

Whenever a new bitcoin block is mined, or a deposit-tx is broadcasted to the bitcoin network, the data will need to be carried to the Nomic-sidechain. Conversely, when a tx is signed by the signatory set in the checkpointing process, it will need to be carried to the bitcoin network. This job is done by relayer nodes: nodes with knowledge of both networks who constantly scan the bitcoin and Nomic chains and broadcast relevant data.

A relayer node has to relay:

bitcoin to sidechain:

• the deposit-tx and a Merkle branch proving it has been included in a bitcoin block.

• the header of the bitcoin block containing the deposit-tx;

sidechain to bitcoin:

• the checkpoint-tx.

---

Security

PoS security incidents resulting in a loss of the reserve funds cannot be reverted, both in the Nomic-sidechain both in the bitcoin-timechain. Also, if over 2/3 of the signatories want to steal the reserve, they can.

For this reason:

• an emergency disbursal is set, protecting against liveness failures.

• a staked token ($NOM) is set as a collateral for signatories. A stake-locking mechanism ensures that signatories are economically disincentivized from stealing from the reserve.

Together with the well known the slashing rules of PoS networks, signatories are also slashed when some of them are found to partially sign a spending-tx for the reserve, while the remaining validators have not signed.

Token creation

Many designs exist to define how the staking token comes into circulation. In order to maintain a fair and decentralized distribution, for instance, tokens could be minted based on a submitted proof of burned BTC, or to Bitcoin miners as a secondary block reward.

BTC Collateralization

Signatories must be overcollateralized relative to the quantity of BTC-reserve they are managing. The minimum value of the collateralization ratio is set to 1.5, otherwise a collusion of over 2/3 of the validators would benefit for stealing the BTC-reserve accepting the lost of their whole staked collateral.

However this strategy is capital inefficient and typically prevented adoption of decentralized custody in favour of centralized platforms. For high capital’s reserve in fact, the overcollateralization is difficult to maintain.

Additional staking reward - Reserve rate

A solution for incentivizing the staked collateral is giving additional staking-rewards, called reserve rate, coming from all the accounts having nBTC. This way, staked collateral grows proportionally to BTC’s deposits.

Different solutions are possible:

• adjusting reserve rate based on the collateralization ratio (when it drops, revenues are higher);

• set a fixed reserve rate and when collateralization ratio drops below the target, BTC-claims would be removed from the network through a forced disbursal, with priority for keeping the claims with higher maximum reserve rates.

A conservative approach is setting the collateralization ratio target > 1,5, especially when token price occilation is taken into account.

Emergency withdrawal

To protect in case of extended liveness failure, signatories also include in the checkpointing process a signature for an emergency disbursal-tx, which will pay back each individual with a BTC-claim. The tx is timelocked for a date 2 weeks in the future, unless a checkpoint-tx is produced over this period (whenever a checkpoint is produced, the emergency-tx is delayed by 2 weeks).

Validators will do everything in their power to prevent extended periods of liveness failure and an emergency disbursal, since if this happens, staked tokens in the sidechain won’t have any value and would be equivalent to an entire slash.

It’s possible to enable a secondary market where traders can speculate on the likelihood of an emergency disbursal happening, which serve as an indicator for the rest of the network by measuring the risks of a catastrophic failure.

---

Additional material

• Taproot upgrade in depth analysis

---

Sources

This article is a summary of a technical article describing the whole bitcoin peg structure, written by Matt Bell, Proof of Stake Bitcoin Sidechains - bitcoin Peg.