Yala Architecture
Last updated
Last updated
Yala architecture includes an application layer, a consensus & data availability (DA) layer, an execution layer, and a settlement layer. The application layer is where the application runs, and the modules on it define the logic of state changes. The module can be a smart contract in the EVM or a tapscript in BRC20. The src parameter in the Vaults Module initiated by the user in the execution layer points to the contract defined by the application layer. Indexer maintains the off-chain status of the system, and transactions of BTC derivative assets are changes in off-chain status, so Indexer maintains consensus on the complex system and maintains data availability. State changes in Yala require Indexer consensus to be executed. Users initiate the Vaults Module based on BRC20 to modify the off-chain status. The Vaults Module is the execution environment for status changes in Yala. Indexer guides the status changes of the Vaults Module based on Oracle's price feed. The status change of BRC20 is eventually reflected as a UTXO transaction, and the transaction in Yala is finally settled in BTC Mainet. Yala's application layer is essentially the logic of state changes defined by smart contracts and Tapscript. The user initiates the Vaults Module and selects the application to be executed by pointing the src parameter to the corresponding contract address. Based on this design, developers can use Yala's SDK to implement customized modules to develop BTC ecological applications.
The application layer in Yala includes loan modules, restaking modules, and stablecoin modules. The stablecoin module forms the foundation of the Yala Finance system, with Yala Finance's stablecoins also being BRC-20. Since BRC-20 cannot be minted, the system maintains a Stablecoin Reserve Pool, essentially the stablecoin module. Users initiate the transfer and withdraw inscriptions to the Stablecoin Issuer Module to simulate traditional stablecoins' mint/burn process. The owners of the stablecoin module are multiple automated running nodes governed by Yala token holders, with these automated nodes executing the withdrawal operations for the stablecoin module.
Yala's stablecoins use an over-collateralization mechanism. Borrowers can initiate a Loan Module, transferring over-collateralized BTC assets to the module through transfer inscriptions. When the Loan Module meets the conditions, automated nodes initiate a Withdraw Module to extract the corresponding $YU to the borrower's address. The Loan Module can only be initiated by over-collateralized participants, with its source pointing to the open-source lending program published by the Yala Foundation, and participants need to modify the init parameters to set their loan amount, initiating transfer inscriptions to the Loan Module based on the asset amount required for collateral as feedback from the indexer. If we expand the multi-sig channel in atomic swaps, upgrading the 2-of-3 multi-signature to an (n-1)-of-n multi-signature channel, this approach is expected to realize a restaking scheme based on BTC Team (2023). [].
DeFi transactions require high throughput and frequently generate large amounts of transaction data. Publishing DeFi-generated data to BTC would incur significant costs; hence, DeFi transaction data cannot be directly stored on BTC. In the Yala system, off-chain state updates and consensus are achieved by Indexer nodes, which also maintain the security and data availability of the off-chain state. This approach saves the cost of uploading data to BTC while providing real-time updates for DeFi states.
Data availability refers to the capability of data stored in the blockchain network to be effectively accessed and used by all participating nodes. Unlike data availability in other blockchains, BTC assets are in UTXO format, comprising two state changes, and the BTC block interval is long, about 10 minutes. When transacting BRC20 or other BTC assets, we need not deal with any data related to the said assets. Indexers capture the global state and balance in the form of witness scripts. Thus, the implementation of data availability in Yala only needs to target off-chain state changes of assets in witness script format, which is maintained by Indexers. The on-chain state change of UTXO is reflected in transfer transactions, which can provide security for off-chain state changes. The change in the off-chain state will eventually be reflected in on-chain UTXO transfer transactions, with BTC's consensus and security verifying the final state of asset transactions on Yala. Assuming that Indexers are trustworthy and that the final changes in the off-chain state synchronize with UTXO transactions, the off-chain state's data availability can be independent of the BTC main chain. Our challenge is implementing Indexers' trustworthiness and the secure real-time update of off-chain states.
Solutions for data availability include Data Availability Sampling (DAS), which has been validated in the EVM ecosystem. In Yala's DA layer, we can directly use DAS to reduce verification costs; validators only need to randomly download part of the data blocks to verify that all data is available. Erasure coding and KZG Polynomial Commitments will also be used to implement DAS in Yala's DA layer. The content to be verified by Yala's DA layer includes transaction data, the Merkle tree of transaction data, and Commitments. Transaction data will be directly verified by Indexers, who will also generate the Merkle tree. Commitments can currently be produced by Indexers as well, and we may consider adding dedicated validators in the future. The proof content will be distributedly stored and made public for a period, set to one month (referencing the storage time of blobs on ETH), during which anyone can verify the proof content. A specialized project is already in development for the BTC DA layer solution; Nubit[^1] is a Bitcoin-Native data availability layer with instant finality. We are considering using Nubit's DA layer solution directly to realize Yala's decentralized Indexer network and DA layer, to ensure the trusted premise assumption of Yala's DA layer Indexers.
In addition, considering another performance requirement of DeFi based on BTC --- the secure real-time update of off-chain states, we have incorporated the Mempool. Mempool is a dynamic staging area for unconfirmed transactions, storing information related to unconfirmed transactions. BTC's long block interval could limit DeFi's TPS (Transactions Per Second). By using Mempool, Yala can complete interim state changes of DeFi transactions after Indexer consensus, pack multiple DeFi transactions into a batch, compute all state changes within the batch to aggregate into the final UTXO state change transfer transaction, and submit it to the BTC main chain for settlement. This process is essentially an off-chain state change Rollup, except that its verification process is executed off the BTC chain, ultimately reflected as a UTXO transaction on the BTC main chain.
The execution layer includes the Oracle and BTC Vaults Module. All DeFi transaction actions in Yala occur within Vaults Modules.
Oracle module: Vaults require real-time market price acquisition of collateral assets to determine when conditional executions are triggered. The Yala Foundation is responsible for maintaining the Oracle Module and Oracle Security Module (OSM). The Oracle Module obtains price inputs from off-chain sources. Off-chain Oracle nodes retrieve necessary data through off-chain data APIs, format it, and return it to the Oracle Module. To protect the system from attackers attempting to control the majority of oracles, Yala Protocol uses the OSM to receive price inputs rather than directly from oracles. OSM acts as a defense layer between oracles and the protocol, publishing prices with a 30-minute delay to allow for emergency defenses in case of oracle compromise. The Yala Foundation makes decisions on emergency oracles and the duration of price delays.
BTC Vaults module: To accommodate native DeFi transactions for BTC assets, Yala has set up the BTC Vaults Module, mapping BTC to on-chain BRC-20 tokens, enabling BTC to be transferred to BRC-20 Modules and participate in DeFi transactions.
The BTC main chain finalizes transactions. In the Yala system, the transfer, withdrawal, and ownership transfer of inscription assets are essentially UTXO transactions. We ultimately attribute the security of complex DeFi logic to the security of UTXO transactions, successfully relying on BTC's consensus and security and utilizing BTC's maintenance of the UTXO state ledger as the transaction state data availability for the system.
