Interoperability

Secure state channels between modules

In Yala's architectural design, state changes operate in an independent environment, creating state channels running within UTXOs on BTC. These state channels provide security, with the occurring changes being off-chain, thus not burdening the BTC main chain's load. The execution function for state changes is stored in MAST conditional circuits scripts in the Witness on BTC. It simply evaluates if the conditions for state change are met without conducting substantial complex calculations, ensuring the contract's security, simplicity, and transparency.

Analyzing the size and content of BTC blocks, according to information provided by bitaps, although the block weight of BTC blocks is limited to 4MB, the average size of the block weight is only 1724885 bytes (Data on March 10, 2024) when the Base size is close to 1MB. Therefore, at least 2MB of space can be fully provided to the witness, with an average of approximately 3500 transactions per block. We can estimate that if each transaction uses taproot script-path spend scripts in the witness to place contracts, each contract averages 600 bytes.

BRC-20 Modules' conditional circuits prescribe the rules for state changes, necessitating MultiSig Vault. The interaction process broadly aligns with the MultiSig Vault setup, involving DeFi participants (excessive collateral borrowers or atomic swap participants), oracles, and Token Modules. The oracles are decentralized and considered trustworthy after processing by the Oracle Module's OSM. Token Modules are divided into Stablecoin Modules implemented by MAST and token contract modules on other chains. The Stablecoin Module determines the permission conditions allowing users to withdraw $YU, and participants also initiate transfers to it during settlement, with the transfer operation being freely executed without permission. In atomic swap scenarios, token contract modules on other chains have Turing completeness and the contract security of different chains. Token Modules are automatically executed under the consensus of Indexers and can be considered trustworthy. We believe such state channels are trustworthy under conditions where only the single transaction participant is untrustworthy.

When DeFi participants initiate the transaction module, its source will be the DeFi transaction script published by the Yala community. The transaction process forms a 2-of-3 multisig state channel between the participant, Oracle Module, and Token Module. The unlocking conditions are two: one is controlled by a time lock, and if participants do not return the borrowed assets within the specified time, the assets will be directly paid to the Token Module. MAST conditions control the other, setting the wager on whether participants can repay the loan. In the borrowing scenario, currently, only over-collateralized loans with pre-set interest values can be implemented, meaning the interest and loan duration are predefined from the start, not variable over time, due to the script size limitations currently supported by the Witness.

Atomic swap

We can readily observe the limitations of operating assets on the BTC main chain. Therefore, we can expand BTC by enhancing its interoperability to facilitate more complex DeFi transactions with BTC assets. Participants need to initiate an atomic swap module on the BTC main chain, pledge a certain amount of BTC or other assets, and then obtain an equivalent amount of wrapped tokens (yBTC) on another blockchain to engage in the DeFi ecosystem of different chains.

We refer to the atomic swap protocol proposed by TierNolan on Bitcointalk[^2]:

1. Party 'A' generates some random data, $x$ (the secret).

2. Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'x', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.

3. Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back.

4. 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the transaction is not finalized anyway.

5. 'B' performs the same scheme in reverse on the alternative chain. The lock time for 'B' should be much smaller than the lock time for 'A'. Both sides of the trade are now pending but incomplete.

6. Since 'A' knows the secret, 'A' can claim his coins immediately. However, 'A', in the process of claiming his coin, reveals the secret 'x' to 'B', who then uses it to finish the other side of the trade with ('x', key 'B').

In the design of Yala's atomic swap protocol, we utilize the Modular BRC20. The protocol process begins with user A initiating an atomic swap contract white module targeted at a specific chain. The randomly generated number $x$ and the lock time $t_1$ are written into the unlock script of the white module. There is a contract on the target chain that interacts with the user, defined as role B, which executes automatically. The unlock condition for the white module is [ if (x for H(x) known and signed by B) or (signed by A & B), ] if not successfully signed and unlocked, a refund transaction to the user will be initiated after time $t_1$. Then, user A initiates a transfer transaction to the white module, transferring a certain amount of BTC into it. The indexer captures the white module, triggering the execution of the atomic swap contract on the target chain, initiating an equivalent yBTC transfer transaction to the user's account on that chain with the unlock condition [ if (x for H(x) known and signed by A) or (signed by A & B), ] If not successfully unlocked within time $t_2$, the transaction will be canceled, where $t_2 < t_1$. User A signs the transaction on the target chain and uses and reveals the secret $x$, acquiring yBTC on the target chain. Contract B captures the secret $x$ and simultaneously unlocks the white module. The final unlock of the white module requires consensus through the indexer; at this time, the ownership of the white module belongs to the Indexer network. The BTC assets pledged within the white module will only be used if a user from another chain exchanges yBTC back to BTC. The entire atomic swap process is monitored by the Oracle, and the contract on the other chain will decide whether to allow atomic swaps based on whether the number of pledged BTC counted by the Oracle is equal to the number of issued yBTC.