Disclaimer: This article is intended for general information purposes only and does not constitute legal, business, investment, or tax advice. It should not be used as a basis for making any investment decisions or relied upon for accounting, legal, or tax guidance. References to specific assets or securities are for illustrative purposes only and do not represent recommendations or endorsements. The opinions expressed in this article are those of the author and do not necessarily reflect the views of any affiliated institutions, organizations, or individuals. The opinions reflected herein are subject to change without being updated.

Author: Taeheon Lee (@CryptKachu), Jungwoo Pyo (@hi_jakepyo)

Reviewer: 100y (@100y_eth)

If you want to discuss or share your opinions about the RWA protocol, please send a direct message to the Lano Technology Twitter account or an email to research@lano.im.

In this piece, we will delve into the crucial topic of handling risk management for Real-World Asset (RWA) tokens. We will analyze how various protocols are tackling these associated risks and discuss any troubles they may have experienced so far. Following this, we will explore the ways in which DeFi protocols are penetrating the lending market collateralized by RWAs. To conclude, we will evaluate a range of perspectives about RWAs in the web3 domain, while also considering the unique benefits and constraints these assets may introduce to the Web3 industry.

1. Managing default risk for RWA-backed loans

In the following section, we will be discussing the notable default risk associated with using RWA as collateral and the strategies that have been put in place to mitigate this risk. Before diving into the details, it’s crucial to comprehend the risks tied to the use of token collateral in traditional DeFi and the ways existing DeFi protocols tackle default risk. We will commence with some fundamental context, then shift our focus to how defaults in loans backed by RWA tokens differ, and examine how various RWA protocols approach these challenges.

1.1 Loan position defaults in previous DeFi protocols.

In the previous DeFi model, when a user deposits stablecoins into a protocol, they only need to take care of the mechanisms of the protocol whether they are able to protect the value of the deposits. In other words, it is crucial to evaluate whether the protocol would be able to perform processes such as liquidation when the price of the collateral token of a borrower drops. For example, if you were a depositor of USDC on AAVE, all you had to worry about was that when the price of the ETH collateralized by the lenders dropped, the protocol would liquidate the lenders’ positions and protect your USDC. The same is true for MakerDAO. All it had to do to keep the value of DAI at $1 is to liquidate the borrowers’ collateral positions before the value of the collateral held by MakerDAO fell below the value of the DAI issued as loans.

So from the depositor’s point of view, they only need to check if the protocol is using proper mechanisms from major protocols like AAVE or MakerDAO, and if there were any cases of defaults. From the protocol’s point of view, when defaults occurred, it checks what is wrong with the mechanism, and only modifies the mechanism appropriately to deal with the default.

1.1.1 Examples

In March 2020, MakerDAO experienced a large number of defaults due to a sharp decline in token prices. The problem at the time was that MakerDAO’s liquidation mechanism was poorly designed, preventing liquidators from participating in the liquidation process as required by the protocol. MakerDAO made improvements to the protocol during the recovery phase, including a significant revision to the collateral auction process of their liquidation mechanism.

In addition to liquidation mechanisms, existing DeFi protocols have risk parameters associated with liquidation to prevent defaults. With a help from a token economy modeling firm called Gauntlet, DeFi protocols such as MakerDAO and AAVE have set loan-to-value (LTV) thresholds for liquidations to occur, and adjust these parameters whenever they believe the market is in a bear market to ensure a protection of their collateral assets. For example, in December 2022, the AAVE community increased the collateral required for stablecoin loans in response to a slowdown in the cryptocurrency market.

1.1.2 Summary

In previous DeFi, if a protocol gets the right price for its token assets and disposes of its collateral at that price, it will not default. In other words, in the traditional DeFi model, if a protocol defaults, it is a problem with the protocol design, thus it means that the protocol is poorly designed or has not properly considered the risks that may arise in the protocol.

1.2 Loan Position Defaults in the RWA Protocol

1.2.1 Awareness of Borrower Defaults

Protocols dealing with RWA think about defaults a bit differently: they recognize that each RWA token collateral may default, and they don’t consider it the protocol’s obligation to prevent it from happening.

In conventional DeFi, when the price of the collateralized tokens falls below a certain level, they can be sold to the on-chain market. However, RWA tokens do not have a market where they can be sold instantly at a set price. Therefore, even if the price of RWA falls, it is difficult for the protocol to properly sell the collateral to protect the value of the protocol assets. Furthermore, no matter how tokenized RWA is, it is still unclear whether token ownership on the blockchain reflects ownership of the actual RWA. These two factors make it actually impossible to quickly liquidate collaterals on the blockchain and redeem the borrower’s loan position when the RWA token collateral needs to be liquidated.

1.2.2 Tranche: A Mechanism for Responding to Defaults

For this reason, the RWA protocol assumes that a default can occur at any time, and the focus is not on preventing the protocol from defaulting through liquidation, but rather on how to allocate the loss of assets to Lenders in the event of a default. To be more specific, some Lenders may be willing to make deposits because they want a high-interest return, even if there might be some loss of capital, while others may prefer not to incur any losses, even if the return is low. The RWA protocol categorizes Lenders and their deposits based on their risk preferences, even for the same vault.

This structure is called a tranche in traditional finance, and most RWA protocols adopt the tranche structure when accepting deposits from lenders. Tranches are usually divided into senior tranches and junior tranches. A senior tranche is a form of funding that is protected against losses but acquire limited returns, while a junior tranche is a pool that can receive a higher return in exchange for being the first capital to be exposed to losses.

Vaults that accept lender deposits in a tranche structure are also designed in the same way as tranches used in traditional finance. When a borrower repays the amount they borrowed plus interest, the repayment is first allocated to the senior tranche and then distributed to the Lenders who deposited in the junior tranche. Any remaining amount will be distributed to the junior tranche. In the event of a Borrower bankruptcy, any losses on the outstanding amount will be applied first to the junior tranche. When the junior tranche alone is unable to recover all of the outstanding amounts, the losses will be applied to the senior tranche as well.

1.2.3 GoldFinch Finance’s senior tranche

TrueFi’s Structured Credit Vault and Centrifuge Tinlake’s Tin & DROP both have senior and junior tranches per vault. However, GoldFinch Finance has a slightly different tranche structure. Here, lenders who deposit assets directly into a specific vault are called backers, and all of the backer’s deposits are recognized as junior tranches. Conversely, lenders who deposit money into the GoldFinch protocol rather than into a specific vault are called liquidity providers, and their deposits are recognized as the senior tranche. The distribution of how many backers deposit capital per vault determines how much of the capital pooled in the senior tranche is allocated to each vault. The result of this is that each VAULT is able to borrow more liquidity than the capital provided by the BACKERS, and in that sense, the model is called a leveraged model.

Let’s speculate on why GoldFinch is using a different senior tranche structure than other RWA protocols. First, GoldFinch’s target borrowers are all businesses in the developing world, even if they have different characteristics, so it seems natural to bundle all of the vaults that GoldFinch has lent to and create a deposit product for their risk and return, and then package that senior tranche as a diversified investment in financial products in the developing world and offer it to users. Other RWA protocols, on the other hand, are so different in terms of who they are lending to, that I don’t think it would have made sense to bundle all of the loans in the protocol into a single deposit product.

1.3 Design considerations for the Tranche structure

1.3.1 Funding the Junior tranche is important

As described above, in the RWA token collateralized lending protocol, if the borrower is unable to repay the loan, the protocol is exposed to non-repayment damage, and the lenders of these vaults may not be able to get their tokens back. Considering that lenders are mainly token holders who deposit stablecoins and want to earn a return with relatively little risk of losing their assets, there needs to be a way to limit the size of the lender’s loss in the event of a borrower’s bankruptcy.

In the current RWA token-backed loan protocol, the junior tranche fulfills this role. The fact that the junior tranche acts as a buffer against losses creates a situation where ordinary investors can invest in RWA protocols with relative ease. In other words, in RWA token-backed loans that are not “risk-free,” the junior tranche is acting as insurance for each loan position. RWA protocols need to be concerned with ensuring the size of the junior tranche deposit, monitoring that the junior tranche that exists in each vault is providing a sufficient return to the junior tranche depositor.

1.3.2 The ratio of junior and senior tranche sizes should be set well

If the size of the junior tranche is too small relative to the size of the loans originated in the vault, the junior tranche alone will not be able to absorb enough of the losses; in that respect, the junior tranche should not be too small. Conversely, if the size of the junior tranche is too large, there’s a chance that you won’t receive enough interest income for putting money into the junior tranche because of the structure of the junior tranche, which is distributed to the senior tranche and receives any leftover interest. This means that you need to set the size ratio of the junior tranche to the senior tranche appropriately. This ratio can be set by considering the following factors

• Borrower’s probability of non-repayment and expected losses The higher the probability of non-repayment in your vault, the larger the junior tranche should be. To determine a borrower’s probability of non-repayment, you can use the following information: The Borrower’s past lending and repayment history, the price stability and ease of disposition of the RWA pledged by the Borrower, and overall market conditions.
• Competitiveness of the junior tranche in terms of yield The interest yield that can be expected from the junior tranche should be naturally higher than the senior tranche, and at least moderately higher than the interest yield that can be earned on stablecoins in other DeFi, so that token holders have an incentive to deposit their assets in the senior tranche.

The RWA protocol should constantly monitor the above factors to track whether the junior tranche can maintain its size. If the return on junior tranche deposits is low, it is advisable to reward junior tranche depositors with tokens from the protocol.

1.4 Case Study

1.4.1 Default Cases

In 2022, news of defaults in the vaults of the RWA protocols have been coming out in rapid succession: first, a $3.4M loan from TrueFi to Blockwater Capital defaulted. Invictus Capital, a crypto fund that borrowed money from TrueFi, also failed to repay a $1M loan on time. Maple Finance also failed to get paid back the 2,400 WETH it lent to Auros Global, a crypto fund. In addition, a series of defaults in vaults managed by Celsius, Alameda, Orthogonal Trading, M11, and others led to Maple Finance defaulting on a $54M loan in December 2022. In addition to Maple Finance, $4.4M in defaults occurred at TrueFi and $2.5M at Centrifuge.

One of the commonalities of the defaults that occurred after October 2022 was that the borrowers were crypto funds, who often put their borrowed assets on exchanges like FTX. They planned to use the loans from the RWA lending protocol to execute their strategies, such as market-making and arbitrage, and make profits to repay the loans and interest. However, when FTX collapsed, their loans were frozen on the exchange, and they were unable to repay the loans from the RWA protocol. In addition to FTX, there is also a case of Invictus Capital that suffered large losses when the Terra stablecoin collapsed and was unable to repay its loan.

In the RWA protocol, when a vault defaults, the losses are shared among the Lenders who funded the vault. When Babel Finance defaulted on a $10M loan from Maple Finance in July 2022, the unpaid amount of the default was charged to the vault’s Lenders, resulting in a loss of about 3.2%.

1.4.2 Protocol Mechanism Improvements

The direction in which Maple Finance changed its mechanisms in the wake of last year’s defaults provides insight into additional default risk management methods that the RWA protocol could consider in addition to the mechanisms described above.

Borrower Diversification — One of the reasons why Maple Finance experienced such a large loan default last year (over $50M) was due to the high concentration of crypto funds in its borrowers. Since the borrowers are all players affected by the crypto market, when an event like the FTX collapse happened, many vaults experienced simultaneous non-repayments. From the protocol’s point of view, such a large number of non-repayments at once creates a burden on the protocol to recover the non-repayment through the treasury created by the protocol. Maple Finance has also recognized this issue and has decided to diversify its borrowers from 2023.

Empowering Vault Administrators — Previously, vault administrators could not declare a default in the event of a borrower’s non-repayment until a certain amount of time had passed. On its face, this may not seem like a problem, as the default is triggered by a mechanism defined by the protocol. However, since there is no way to liquidate the borrower’s collateral to force them to repay the loan, the RWA protocol requires the lender to freeze the vault assets as soon as possible to preserve the lender’s assets as much as possible when it is determined that the borrower has lost the ability to repay. With this in mind, Maple Finance has modified the protocol to allow the vault administrator to declare an immediate default if, in the vault administrator’s opinion, the Borrower has lost the ability to repay.

Aligning Vault Administrator Incentives — An issue that arose during the 2022 default was that some vault administrators did not share accurate information about the status of the vaults they were managing and the repayment status of their borrowers. Given the nature of the RWA protocol, which relies not only on the logic of the protocol, but also on the trust relationships between Lenders, Borrowers, and administrators using the protocol, this behavior by vault administrators can lead to greater losses due to defaults. In this respect, rules are also needed to force vault administrators to deposit a large amount of assets in the junior tranche of a vault when they create it.

2. Entry of DeFi protocols into the RWA collateralized loan market

Since the second half of 2022, one of the most talked about issues in the RWA ecosystem has been the emergence of several projects among existing DeFi protocols that have announced their intentions to incorporate RWA. MakerDAO and AAVE are the most prominent examples, while Frax Finance has also been actively discussing RWA-related mechanisms. In this part, we’ll discuss the context in which MakerDAO and AAVE have tried to introduce RWA, and what form it’s taking.

2.1 MakerDAO

2.1.1 Purpose of Introducing RWA

Stable growth of the protocol — One of the main agendas of the MakerDAO community has always been to create a means to stably increase DAI issuance. One of the problems MakerDAO has faced since running the stablecoin since 2018 is that it has been unable to continue to grow DAI with only ERC20 token collateral. MakerDAO recognized that accepting only token collateral would make DAI issuance too dependent on long demand for the cryptocurrency. By incorporating RWA collateral, MakerDAO hopes that DAI will provide utility as a lending instrument for entities looking to borrow on the basis of RWA or credit. Under this strategy, MakerDAO will no longer rely solely on cryptocurrency market conditions, but will also be able to create demand for DAI based on the real economy. As a result, DAI’s issuance will be able to grow more stably.

Monetization — MakerDAO also initially created a demand for DAI through the DAI deposit fees offered by the protocol, known as DSR, and based on this demand, the interest paid by borrowers became the primary revenue stream for the protocol. However, the MakerDAO community soon realized that the yield from tokens was not high or sustainable, and they started to focus on the yield from RWA, which is quite high and sustainable, and they started to issue DAI directly to entities that want to borrow against RWA and make the yield from RWA the main source of revenue for the protocol.

2.1.2 Adoption Criteria

Whenever MakerDAO creates a vault for a particular RWA or makes a loan secured by an RWA to a particular borrower, it relies on input from its community members to make the decision. In making these decisions, the MakerDAO community has decided to use the following evaluation criteria

• Scalability: First of all, MakerDAO’s position is that the RWA must have a high enough issuance volume and a large enough market size to increase DAI issuance.
• Stability: As RWAs are used as collateral for DAI issuance, it is important that the collateral remains stable in value. To that end, the MakerDAO community determines if the price of the RWAs is sufficiently stable and if there is sufficient liquidity in the market to dispose of them. Furthermore, the protocol assess whether there is any risk that this could jeopardize the stability of MakerDAO.
• Demand: Even if MakerDAO accepts the RWA as collateral and issues DAI, it doesn’t make much sense to accept the RWA as collateral on MakerDAO if it’s better to borrow from a traditional financial institution with the RWA in terms of interest and other financial costs. In this regard, the MakerDAO community evaluates the utility of borrowing on MakerDAO from the perspective of the RWA owner, i.e., if MakerDAO and the RWA owner are mutually beneficial.
• Regulatory Risk: In addition to dealing with RWA, the MakerDAO team also considers whether there are additional regulatory or legal entities that need to be involved in the process of incorporating the asset into the protocol, and whether there are additional technical, economic, or regulatory risks.

2.1.3 Steps required for implementation

In addition, MakerDAO has summarized the steps required to adopt RWA as follows.

• How can RWA assets be converted into tradable assets on MakerDAO? In order to hold RWA as collateral on the protocol, users need to be able to tokenize it and have a legal mechanism in place that allows them to dispose of it in the event of a liquidation.
• Is it possible to prevent a DAI borrower from pledging the same asset again in the traditional financial world? Since the legal rights of tokenized RWA are separated from the rights in the real economy, there is a risk that a borrower may borrow from MakerDAO with their RWA and then take out another loan in real finance. If this happens, it is unlikely that the borrower will be able to repay the loan they received from the RWA protocol. In this regard, MakerDAO tries to prevent borrowers from using their RWA as collateral to obtain another loan.
• Can price information, etc. be reliably retrieved? How will the oracle be designed? Even if there are differences in the way collateral is disposed of in the liquidation process, the value of RWA still has a significant impact on the borrower’s repayment potential because RWA acts as collateral. In that regard, MakerDAO is concerned about how to reliably fetch the value of those RWA assets.

2.1.4 Adoption Status

In July 2022, MakerDAO created the Real World Finance Core unit, which aims to increase MakerDAO’s impact on real-world finance. Through this unit, the protocol team has been making RWA-backed loans to actors in real-world finance and continues to create vaults for them. These vaults are working by issuing DAI directly to borrowers needing loans. You can check out the active RWA vaults here. The main vaults are as follows (as of March 2023)

The amount of DAI issued as RWA collateral on MakerDAO has now exceeded $600M, and the pace of DAI issuance has been increasing rapidly, especially since the end of 2022. Vaults like RWA009-A above are particularly significant because they provide funds directly from MakerDAO that would otherwise be lent by a government-regulated bank. In terms of protocol revenue, it’s also helping to improve the protocol’s bottom line, with DAI issued as RWA collateral worth around $650M generating around 75% of the protocol’s total fee revenue as of January 2023.

Against this backdrop, MakerDAO continuously reviews vaults that lend DAI as collateral for RWA, such as short-term bonds, institutional credit, and energy production facilities.

The MakerDAO community has expressed that it is inefficient and slow for each RWA to have to go through governance to decide whether or not to handle the asset. As a result, MakerDAO is looking to partner with RWA tokenization and RWA collateralized lending protocols such as Centrifuge (+ Tinlake) to allow the RWA protocols to take care of the necessary steps in handling RWA assets. MakerDAO is also in talks with Maple Finance about a partnership. Here again, Maple Finance will be utilized as the infrastructure to facilitate RWA-based collateralized loans, and MakerDAO will likely issue DAI to Maple Finance and adjust parameters such as DAI issuance limits and default interest rates for each vault based on the risk of the vault. In a partnership with RWA Protocol, the roles that MakerDAO expects the other protocol to play are as follows: 1) onboarding and managing borrowers, 2) conducting legal proceedings or organizing legal structures, and 3) handling defaults.

2.2 AAVE

2.2.1 Background

The rise of GHO — In July 2022, the Aave Governance Forum, in an agenda item called “Introducing GHO”, proposes a plan to issue a stablecoin called GHO based on the Aave protocol. Like other stablecoins, GHO would be backed by multiple asset classes. Still, instead of being crypto-specific, it was notable that it would be a mix of assets that were less correlated to each other, such as RWA and credit score.

In the GHO mechanism, instead of a single entity managing all collateral, an entity called a facilitator is authorized to issue GHO tokens. Facilitators propose a method for issuing GHO to the community, and if the proposal passes, GHO can be issued in the manner proposed by the facilitator, within certain limits. Interestingly, Facilitators do not have to insist on issuing crypto-collateralized stablecoins; in fact, GHO can be issued/burned in any way that each Facilitator defined, including collateralization against multiple asset classes, algorithmically, credit-based or delta-neutral position-based, and the more diversified the Facilitators, the more stable the price of GHO will be.

The Importance of RWAs in DeFi — In November and December 2022, the Aave community began to discuss the importance of RWAs. In “Helping Aave Think Through RWAs”, Punia from Warbler Labs noted that RWAs could help the Aave protocol in two ways: by providing stability through the diversification of stablecoin collateral outside of crypto and by paving the way for GHO to scale as a global stablecoin by leveraging a larger pool of assets than can be leveraged with crypto.

In “Why RWAs are Important to DeFi”, the author argue that while DeFi can achieve a certain amount of growth (10x~) by focusing on crypto natives, there is a clear limit to the size of the crypto market and that RWAs are necessary to achieve even greater growth (100x~) beyond that. DeFi needs to get some market share from TradFi to enter the mainstream eventually.

• DeFi and TradFi are analogous to the reversal of the ratio between e-commerce and in-store transactions, where people prefer e-commerce to in-store transactions now that the internet is available. The same is true for DeFi and TradFi: as blockchain technology develops and becomes more active, people will favor DeFi over TradFi.
• Finance is a field where user needs are always present, and people always want flexibility in their financial applications and funds, which is a universal phenomenon. DeFi can serve them better in all these ways.
• The visibility and interoperability of DeFi make it safer and less volatile than centralized protocols and better serve the economic system as a whole.

Success on MakerDAO — The success of MakerDAO further strengthens the case for RWA on Aave Protocol. Securing a steady stream of revenue from a DeFi protocol is crucial to its sustainability, and according to the article “Outlining an RWA Strategy For Aave”, as of November 2022, MakerDAO received over 50% of the protocol’s revenue from RWA.

The dashboard above shows the evolution of MakerDAO’s revenue by asset, with RWA accounting for well over 50% of revenue as of March 2023. With RWA accounting for a larger and larger share of total revenue over time, it’s clear that RWA is more important than we might think.

2.2.2 Effects and expected results

According to the article “Outlining an RWA Strategy For Aave”, the risks of Aave including only on-chain assets as collateral for GHO are as follows:

• During market downturns, there is a risk of accumulating liabilities in the protocol if there is a lack of market liquidity in the relevant assets, i.e., there is a risk of protocol default if only crypto assets are treated as collateral.
• The lack of liquidity in a protocol eventually makes it vulnerable to economic attacks or liquidation.
• Cryptocurrency assets are highly sensitive to market conditions, and during market downturns, the cash flow of lending protocols can deteriorate due to lower demand for leverage.

Ultimately, the Aave community expects to see the following effects when RWA assets are offered as collateral for GHO. This overall statement is broadly consistent with the effects the MakerDAO community expected when they decided to accept RWA.

• Because RWA is more stable and less volatile than crypto assets, its risk is more dependent on macroeconomic flows, and it is more robust to the volatility of the narrower crypto market itself.
• RWA borrowers’ financing is often for productive businesses, not speculative trading. This is a much larger scale than crypto speculation and is consistent regardless of bull and bear markets.

2.2.3 Aave’s RWA adoption strategy

RWA is a completely different asset class compared to traditional cryptocurrencies. There’s a lot of discussion in the Aave community about how RWA should be implemented. In the article “Outlining an RWA Strategy For Aave,” the author has broken down the different elements of DeFi to see which ones are being advocated.

• Asset types: The author argues for introducing less risky, lower-yielding RWA first to see how it works in the crypto market to build long-standing trust in RWA facilitators, and then progressively introduce riskier, higher-yielding assets. The asset classes should not be directly correlated to the crypto market, for example, by excluding loans to makers, miners, DAOs, etc.
• Debt Ceiling: In the real world, adopting GHO as a fiat currency will take time, so we must assume that all borrowers will initially exchange GHO for an existing fiat (USDC, USDT, USD, …). This is why the assigned debt ceiling should be proportional to the liquidity available to sell or redeem for existing stablecoins, as, ultimately, it is important for GHO to remain soft-pegged to USD to maintain its value. To summarize, the debt ceiling should be such that it will not depreciate if a significant amount of GHO is sold into the market.
• Interest Rates: The author argues that Aave’s current interest rate model should not be applied to RWA and that interest rates should be based on underwriting and TradFi-like deals. This is because Aave’s facilitators can set interest rates for RWA differently than other asset classes.

2.2.4 Adoption Status

On December 28, 2021, Aave partnered with Centrifuge to launch the RWA market for the tokenization of RWA (https://rwamarket.io/). Offering Centrifuge Tinlake’s TIN & DROP model within the Aave service, RWA market allowed depositors to earn yield on stable, crypto-correlated RWA collateral, and Centrifuge issuers to use the crypto market as an alternative source of liquidity by lending through Aave.

Since the RWA market is a closed market, only users who have been verified through a KYC process to become a depositor can participate as an investor. Issuers (Centrifuge Issuers) can create pools for their assets, and LP tokens correspond to the DROP of Centrifuge Tinlake. Depositors (investors) can stake their deposits with USDC to purchase DROP from that pool.

Immediately after launch, the size of the RWA market grew rapidly, exceeding $20M in April 2022, but later, during the market downturn, the market size shrank, and the total market size was around $7.5M as of March 2023. Fortunately, no capital defaults occurred, and the protocol itself works as intended.

Through the operation of the RWA market, Aave has learned that several key challenges need to be addressed to bring RWA to DeFi in earnest.

• It needs various domain experts related to Risk Assessment (RA) or Underwriting.
• Lenders should consider their strategy carefully, considering the duration and liquidity of RWA collateral, as it is an inherently different class of asset than highly liquid types like crypto.
• RWA’s funding depends on Aave’s stablecoin liquidity, which can often be affected by factors outside of Aave.

RWA facilitators. The example of the RWA market has shown us the potential for bringing RWA to DeFi. We’ve seen how the discussion of an RWA facilitator as one of the facilitators for the issuance of GHO is progressing. As of December 2022, according to the Aave community proposal “Centrifuge’s Perspective of an RWA Facilitator for GHO”, Centrifuge is continuing to attempt to become a full-service RWA facilitator for GHO.

In the previous article, we identified a number of key challenges that need to be addressed to make RWA scalable. In the Aave protocol, we expect the RWA facilitator to have the following roles:

• Compatibility with DeFi: This refers to ensuring that RWA collateral is well integrated into the on-chain ecosystem.
• Trusted infrastructure: Conducting intermediation involving RWA collateral requires a high level of transparency within a sound legal framework. A trusted, professional brokerage framework is required to onboard RWA into the on-chain ecosystem successfully.

Centrifuge is currently developing an index token based on the assets held by the Centrifuge pool. As an index to the entire pool, purchasers of the index token will purchase a portfolio of centrifuge assets, which is the result of risk diversification thought out by the collective intelligence of the credit group within the ecosystem. The RWA pool can also be included as a portfolio composition of the index, and this may be the best case of RWA experience as an Aave GHO facilitator.

3. The state of the RWA mortgage market and what’s ahead

So far, we’ve described the mechanisms used by the protocols that handle RWA tokens and why they are designed the way they are. In this part, we’ll take a quick look at the current state of the protocols that handle RWA tokens. We’ll start with the overall trend in lending volume and then cover how each protocol is doing.

3.1 TVL and overall loan volume trends

3.1.1 The growth and contraction of lending to crypto funds

Below is a graph showing the active loan volume of protocols that are lending against RWA tokens. Before 2022, TrueFi accounted for the majority of RWA collateralized loans, which is partly due to TrueFi being the first RWA collateralized lending protocol. After that, Maple Finance grew rapidly until the second half of 2022, when Maple Finance and TrueFi bisected the RWA collateralized lending market.

The composition of borrowers that Maple Finance and TrueFi lent to during this time was dominated by crypto funds that engaged in crypto-based market making and trading, such as MGNR, Auros capital, Folkvang trading, and Alameda research. Until the second half of 2022, it seems that Maple Finance and TrueFi experienced rapid growth as trading companies needed more funding due to the crypto bull run.

However, as we move through the second half of 2022, events like the collapse of Terra Protocol and the FTX bankrun have taken a toll on major crypto funds, and the volume of lending to crypto funds has dwindled accordingly. As a result, the weight of Maple Finance and TrueFi in the graph above virtually disappears from 2023 onwards.

3.1.2 Stable growth in lending to non-crypto funds

While Centrifuge and GoldFinch haven’t seen the same explosive growth as Maple Finance, they have grown steadily since 2022 and appear to have maintained their overall loan volume through the big events of the second half of last year without much damage. Here, Centrifuge is lending across various asset classes, including loans secured by real estate and loans secured by freight invoices. GoldFinch is lending to FinTech companies and real estate firms in developing countries. The figure below shows Centrifuge’s lending by sector, and they are actually lending to various sectors, including real estate, developing countries, and institutions.

Centrifuge and GoldFinch seem to have been spared much of the damage last year because their lending is not concentrated in crypto companies but rather in non-crypto companies, and in that regard, the demand for borrowing from them remains strong and has been growing steadily regardless of the state of the crypto market.

3.1.3 Increasing RWA Collateralization in DeFi Lending Protocols

In addition, as mentioned above, stablecoins and lending protocols like MakerDAO, AAVE, and FRAX are actively entering the RWA collateralized loan space and are slowly increasing the percentage of RWA assets within their protocols. FRAX has been discussing the allocation of FRAX to RWA collateralized loan pools through governance forum discussions since June of last year and has voted on partnerships with companies like TrueFi and PropFi. While we’re still very new to the RWA collateralized lending mechanism in DeFi, it will be interesting to see how fast this space grows over the course of 2023.

3.2 Benefits of utilizing RWA

3.2.1 Attracting real economy players to the DeFi ecosystem

It’s still true that most of the users of products like DeFi and NFTs are concentrated in a small number of people who have been owning and trading cryptocurrencies for a long time, so to grow the Web3 ecosystem, we need to onboard more users into the Web3 ecosystem. Various initiatives are underway, such as the Web2 X Web3 partnership, and RWA token-backed loans could be one of them.

If RWA collateralized loans can provide value to investment firms and institutions that traditional finance can’t and bring their liquidity into the DeFi ecosystem, it could act as an impetus to grow the overall size of the Web3 ecosystem once again. By slowly bringing more institutions into the Web3 space through the RWA protocols, blockchain can be positioned as an infrastructure for new financial technologies. Bringing RWA tokens into the DeFi ecosystem is a big step towards broadening the user base.

3.2.2 DeFi can have other means of monetization besides tokens

As previously discussed, RWA collateral allows blockchain projects to generate revenue from sources other than cryptocurrency. The problem with traditional crypto-based incentives is that they’re too dependent on market conditions, and they don’t provide meaningful or sustainable returns.

However, by utilizing interest income from RWAs as a new revenue stream, DeFi protocols can have a revenue stream other than their newly issued tokens, which can be attractive from a DeFi perspective, especially if the risks associated with RWAs are well-understood and managed. In fact, if you look at the rwa.xyz webpage, you’ll see that the average interest yield from RWA handled by DeFi protocols is 10%. Since most of MakerDAO’s revenue comes from its RWA vault, protocols can broaden their revenue streams if they get RWA right.

3.2.3 Secure demand that is not affected by the DeFi cryptocurrency market

One of the biggest problems with blockchain projects in any domain, whether it’s DeFi or NFTs, is that they’re all too heavily influenced by the cryptocurrency market, represented by Bitcoin. This problem is exacerbated for DeFi lending protocols because the people who deposit fiat tokens (ETH, UNI, etc.) on DeFi lending protocols and try to lend are usually people who are trying to leverage their long positions by borrowing. Conversely, people who deposit stablecoins on DeFi lending protocols and want to borrow fiat tokens represent short positions.

So if you look at DeFi protocols like MakerDAO or AAVE, you can see that the size of the protocols increases and decreases dramatically depending on market conditions. But if it includes the entities that own RWA in the user base, these protocols have a demand that’s relatively unaffected by the crypto market and that allows them to operate with some degree of predictability in terms of the size of the protocol.

3.3 Disadvantages or Limitations of Utilizing RWA

3.3.1 Trust issues arise

In addition to the advantages in terms of cost and transaction speed, the ability to achieve expected results through blockchain and smart contracts without having to trust a centralized party has been one of the most important values of DeFi. However, most DeFi activities that use RWA tokens as collateral are based on trust. Lenders have to trust a third party in each vault when they deposit their money, and then they have to trust that the borrowers will repay the loan honestly.

Suppose you look at what’s happened in the RWA protocol over the past year. In that case, we’ve had vault defaults and borrowers not redeeming because the third party in the vault was not acting honestly. We’ve had cases like that, and we’re going to continue to have these trust issues until there’s a more solid legal and institutional foundation around the RWA token, and even then, we’re likely to be using this protocol with some level of trust issues compared to fully crypto-native DeFi.

3.3.2 Only certain users are eligible for loans

In the RWA Lending Protocol, we mentioned that a certain amount of trust is required between lenders, borrowers, and third parties, and it is true that RWA token-backed loans are used for under-collateralized lending. However, because of the need for trust between actors, the group of users who can borrow through the RWA Lending Protocol is still concentrated in certain institutions. Look at products such as Centrifuge, GoldFinch, Maple Finance, etc. You can see that the entities that are borrowing or acting as administrators through this protocol are concentrated in institutions with a certain amount of reputation and expertise. In this respect, there is no market where ordinary people can easily borrow against RWA as collateral.

3.3.3 Does it really reduce costs?

Smart contracts can indeed reduce the cost of many arbitrations that occur during financial transactions. However, in the case of RWA protocols, the process of tokenizing the RWA, identifying the borrower, and the risk of the RWA incur additional costs because it requires experts with knowledge of the RWA and entities to handle legal and administrative tasks. In fact, some protocols require establishing a special-purpose vehicle for each vault. In this respect, there are still multiple costs associated with RWA. This limitation will continue to exist until the infrastructure for each RWA is in place and the risk assessment criteria for each asset are somewhat established.

3.4 Personal Opinion on the RWA Protocol

RWA has a lot of value in that it can solve some of the limitations of the blockchain ecosystem and some of the inefficiencies of traditional finance simultaneously. Once we get some administrative guidelines around RWA in 2023, RWA will get a lot more attention from the blockchain market, and that’s why RWA tokens are getting a lot of attention, and this market will grow in the future.

3.4.1 The need to recognize a different identity from traditional financial or Web3 products

But for a protocol that deals with RWA, it’s based on a very different philosophy than what many DeFi or blockchain projects are based on. This is because everything is not handled through smart contracts like the existing Web3 products, but to some extent, you have to trust someone and accept the problems that come with it. This is a very different characteristic from the existing Web3 products that people who have been in Web3 have seen, and the protocols that deal with RWA are located somewhere in between the existing financial system and Web3 products.

In this regard, when protocols deal with RWA, it is necessary for them to clearly understand not only the value they can bring to the existing financial sector and the blockchain ecosystem through their services but also why they are trying to deal with RWA and the various problematic situations and constraints that may arise in the process, both for those in the existing financial sector and the blockchain ecosystem. And protocols should be aware of the problems that may arise due to the transparency and centralization of information as they operate and improve them so that the RWA market can develop into a more mature industry.

3.4.2 The importance of risk management

As I keep mentioning in this article, the protocols that deal with RWA are still centered around lending protocols, and the lending that happens here is in the form of credit. Since the lending itself is often done for leverage purposes, the lending system itself can be destabilized at any time during the process of over-expansion and investment. This risk can be even more devastating to the protocol, especially since the lending is not regulated and monitored like traditional finance but can be done at the discretion of a third party that exists in each vault.

Most RWA protocols are not yet fully equipped to deal with these risks, so protocols are currently forced to rely on opaque information disclosure (compared to traditional Web3 products), the behavior of certain actors, and the unregulated nature of their mechanisms. Against this backdrop, each protocol must consistently take care of the way to manage these risks.

About Us

Four Pillars is a global crypto research firm based in Seoul, consisting of the most influential blockchain researchers in Korea. Through robust research and governance skills, it helps various market players easily onboard to the blockchain industry by offering high-quality research articles while supporting protocols in their expansion into Korean and global markets.

Four Pillars Links

• Website (EN/KO)
• Twitter (EN/KO)
• Telegram (KO)

The Mechanism and Ecosystem of RWA Protocols was originally published in Four Pillars on Medium, where people are continuing the conversation by highlighting and responding to this story.

면책 조항: 본 글은 일반적인 정보 제공을 목적으로 작성되었으며, 법률, 사업, 투자 또는 세금 관련 조언을 제공하지 않습니다. 본 글을 기반으로 투자 결정을 내리거나 이를 회계, 법률, 세무 지침으로 사용해서는 안됩니다. 특정 자산이나 증권에 대한 언급은 정보 제공의 목적일 뿐, 투자에 대한 추천이 아님을 밝힙니다. 본 글에서 표현된 의견은 저자의 개인적인 의견이며, 관련된 기관, 조직 또는 개인의 견해를 반영하지 않을 수 있습니다. 본 글에 반영된 의견은 사전고지 없이 변경될 수 있음을 유의하십시오.

Author: 태헌이(@CryptKachu), Jungwoo Pyo(@hi_jakepyo)

Reviewer: 100y (@100y_eth)

RWA 프로토콜에 대해서 대화하거나 의견을 주고 받고 싶은 분께서는 Lano Technology 트위터 계정으로 dm 혹은 research@lano.im으로 메일 보내주시길 바랍니다.

RWA 토큰을 다룰 때는 그 실물자산과 관련된 리스크를 관리하는 것이 중요한데, 이번 아티클에서는 프로토콜들에서 이 리스크들을 어떻게 다루고 있는지와 지금까지 문제가 발생한 적은 없는지에 대해서 설명합니다. 그리고 나서 DeFi 프로토콜들이 어떤 방식으로 RWA 담보 대출 시장으로 진입하고 있는지에 대해서 설명하겠습니다. 마지막으로는 RWA에 대해 웹3 공간에서 RWA에 대해 나온 여러 의견들을 종합하면서 RWA가 블록체인 공간에 가져올 수 있는 가치와 한계점에 대해서 논의하려고 합니다.

1. RWA 담보 대출의 디폴트 리스크 관리

이번 파트에서는 RWA 토큰을 담보로 활용할 때 특히 신경써야 하는 디폴트 리스크에 대해서 설명하고, 어떤 메커니즘을 통해서 이를 다루고 있는지에 대해서 설명드리겠습니다. 여기서 설명드릴 내용에 대해서 온전히 이해하기 위해서는 먼저 기존 DeFi의 크립토 토큰 담보물에서 발생하던 리스크와 그에 대한 기존 DeFi 프로토콜의 디폴트 리스크 관리 방법에 대해서 이해하셔야 합니다. 따라서 이에 대한 배경을 먼저 설명하고, RWA 토큰 담보 대출에서 발생하는 디폴트는 어떻게 다른지, 그리고 여러 RWA 프로토콜들은 이를 어떻게 다루는지에 대해 설명하겠습니다.

1.1 기존 DeFi에서의 대출 포지션 디폴트 인식

기존 DeFi 모델에서는 사용자가 프로토콜에 스테이블코인을 예치할 때, 프로토콜이 사용자의 스테이블코인의 가치를 잘 지켜줄 수 있는지만 신경쓰면 되었습니다. 이를 달리 말하면 사용자의 스테이블코인을 빌리려고 하는 대출자의 담보 토큰 가격이 떨어질 때 그에 따라 프로토콜이 청산 등의 절차를 잘 수행할 수 있는지만 신경쓰면 되었다는 의미입니다. 예를 들어서 AAVE에 USDC를 예치하는 예치자는 대출자들이 AAVE에 담보로 예치한 ETH 가격이 떨어질 때, 프로토콜은 그에 따라 대출자들의 포지션을 청산시키고 예치자의 USDC를 지켜줄 수만 있으면 되었습니다. MakerDAO도 마찬가지입니다. 대출로 발행된 DAI 가치보다 MakerDAO가 가진 담보물의 가치가 낮아지기 전에 대출자들의 담보 포지션을 청산시키기만 하면 DAI의 가치를 $1로 유지시킬 수 있었습니다.

그래서 예치자 관점에서는 프로토콜이 AAVE나 MakerDAO처럼 주요 프로토콜의 메커니즘을 차용하고 있는지 확인하면 되었고, 비슷한 메커니즘을 사용하는 프로토콜에서 메커니즘으로 인해서 디폴트가 발생한 사례가 있는지만 확인하면 되었습니다. 프로토콜 입장에서도 디폴트가 발생했을때 메커니즘 상에 어떤 문제가 있었는지를 확인하고 그 메커니즘만 적절한 형태로 수정하는 형태로 디폴트에 대처하였습니다.

1.1.1 사례

2020년 3월, 코인 시장이 급격하게 하락하면서 MakerDAO에서 디폴트가 대규모로 발생했습니다. 이 당시 발생했던 문제는 MakerDAO 청산 메커니즘이 제대로 설계되어있지 않아서 청산자들이 프로토콜이 필요로 하는 청산 과정에 참여하지 못했다는 것입니다. MakerDAO는 디폴트 처리 과정에서 자신들의 청산 메커니즘 중 담보물 경매 방식을 대폭적으로 수정하는 형태로 프로토콜을 개선하였습니다.

청산이 일어나는 메커니즘 외에도 기존 DeFi 프로토콜에서는 청산과 관련된 리스크 파라미터들을 통해서 디폴트가 일어나는 것을 방지했습니다. Gauntlet이라는 토큰 이코노미 모델링 회사를 통해서 MakerDAO, AAVE 등의 디파이 프로토콜들을 청산이 일어나기 위한 담보대출비율 (LTV) 기준을 설정하였고, 시장 하락장이 심해진다고 판단될 때마다 이 파라미터를 조정하여서 청산이 원만하게 일어나도록 하고 있습니다. 그 대표적인 예시로, 2022년 12월에 AAVE 커뮤니티는 암호화폐 시장의 둔화에 대응하기 위해서 스테이블코인 대출에 필요한 담보 비율을 높였습니다.

1.1.2 정리

기존 DeFi에서는 프로토콜이 토큰 자산들의 가격을 정확하게 가져오고, 그 가격에 담보물들만 잘 처분하였다면 디폴트가 발생하지 않았습니다. 즉, 기존 DeFi 모델에서는 프로토콜에서 디폴트가 발생하는 것을 프로토콜 설계의 문제라고 생각하였습니다. 그리고 디폴트가 발생하는 것은 프로토콜이 제대로 설계되어있지 않거나 프로토콜에서 발생할 수 있는 위험 요소들을 제대로 고려하지 않았다는 것을 의미하였습니다.

1.2 RWA 프로토콜에서의 대출 포지션 디폴트

1.2.1 Borrower 디폴트에 대한 인식

RWA를 취급하는 프로토콜에서는 디폴트가 발생하는 것에 대해서 다소 다르게 생각합니다. 여기서는 각 RWA 토큰 담보물마다 디폴트가 발생할 수도 있다는 것을 프로토콜 차원에서도 인정하고 있으며, 디폴트가 발생하지 않도록 하는 것을 프로토콜의 의무라고 생각하고 있지도 않습니다.

기존의 DeFi에서는 담보로 받아둔 토큰들의 가격이 일정 수준 이하로 떨어졌을때 이를 온체인 위에 형성되어있는 시장에 매도하면 되었습니다. 하지만 RWA 토큰들은 정해진 가격에 바로 매도할 수 있는 시장이 형성되어있지 않습니다. 그래서 RWA의 가격이 떨어지더라도 프로토콜에서 적절히 담보물을 처분해서 프로토콜 자산의 가치를 지키는 것이 힘듭니다. 거기다가 RWA가 아무리 토큰화되었다고 해도 블록체인 위의 토큰 소유권이 실제 RWA에 대한 소유권을 그대로 반영하는지에 대해서 아직까지는 애매한 상황입니다. 이 두 이유에 의해서 RWA 토큰 담보물이 청산되어야 할 때 블록체인 위에서 빠르게 담보물을 처분하고 borrower의 대출 포지션을 상환시키는 것은 사실상 불가능합니다.

1.2.2 Tranche: 디폴트에 대응하는 메커니즘

이러한 이유에서 RWA 프로토콜에서는 디폴트가 언제든 발생할 수 있다고 생각하고, 청산을 통해 프로토콜 디폴트가 발생하지 않도록 하는 것이 아니라 디폴트가 발생했을때 그 자산 손실을 어떻게 Lender들에게 배분해야하는지에 초점을 맞추고 있습니다. 조금 더 구체적으로 설명해보겠습니다. Lender 중에서도 어떤 Lender는 자본 손실이 조금 발생하더라도 높은 이자 수익을 원하고 예치를 할 수도 있고, 어떤 Lender는 수익률이 낮더라도 손실이 발생하지 않는 것을 더 선호할 수 있습니다. RWA 프로토콜은 같은 vault에 대해서도 Lender를 리스크 선호도에 따라 분류하여 예치를 할 수 있도록 하고 있습니다.

이러한 구조를 전통 금융에서는 Tranche라고 하고 있고 웬만한 RWA 프로토콜들은 Tranche 구조를 가져와서 Lender들의 예치를 받고 있습니다. Tranche는 보통 senior tranche와 junior tranche로 나뉘어 집니다. 여기서 senior tranche는 손실에 대해서 어느정도 보호를 받되 수익률은 제한되어 있는 모금 형태를 말하고, junior tranche는 손실에 가장 먼저 노출되는 대신 더 높은 수익률을 받을 수 있는 채권을 의미합니다.

Tranche 구조로 Lender의 예치를 받는 vault들도 전통 금융권에서 사용되던 tranche와 같은 형태로 설계되어있습니다. Borrower가 자신이 빌린 대금과 이자를 상환하면 이 상환액은 우선적으로 senior tranche에 할당되어서 senior tranche에 예치한 Lender들에게 배분됩니다. 남은 금액은 junior tranche로 배분됩니다. Borrower 파산이 발생했을 때에는 미상환금액에 의한 손실은 우선적으로 junior tranche에 적용됩니다. Junior tranche 만으로는 미상환 금액을 모두 회수하지 못하게 될 때부터 senior tranche에도 손실분이 적용됩니다.

1.2.3 GoldFinch Finance의 senior tranche

TrueFi의 Structured Credit Vault, Centrifuge Tinlake의 Tin & DROP 모두 vault 별로 senior tranche와 junior tranche가 형성되어있습니다. 하지만 GoldFinch finance는 다소 다른 tranche 구조를 가지고 있습니다. 여기서는 특정 vault에 직접적으로 자산을 예치하는 Lender들을 backer라고 하는데, bakcer의 예치금은 모두 junior tranche로 인식됩니다. 반대로 특정 vault가 아닌 GoldFinch 프로토콜에 돈을 예치한 Lender들은 liquidity provider라고 하는데, 이들의 예치금은 senior tranche로 인식됩니다. 그리고 vault마다 몇 명의 backer가 어떤 분포로 자본을 예치했는지에 따라서 senior tranche에 모여있는 자본을 각 vault에 얼마만큼 배분할 지가 결정됩니다. 이에 대한 결과로 각 vault들은 backer가 공급한 자본보다 더 많은 유동성을 대출할 수 있게 되고 그 점에서 이 모델을 Leverage Model이라고 합니다.

그럼 GoldFinch가 왜 다른 RWA 프로토콜과는 다른 senior tranche 구조를 사용하고 있는지 추측해보겠습니다. 먼저, GoldFinch는 타겟으로 하고 있는 Borrower가 세부적으로 차이가 있긴 해도 모두 개발도상국의 사업자라는 공통점이 있습니다. 그러다보니 GoldFinch가 대출을 진행해준 전체 vault들을 하나로 묶고, 그 리스크와 수익률에 대한 예치 상품을 만들어도 자연스럽고, 이러한 senior tranche를 개발도상국의 금융 상품에 대한 분산 투자 상품으로 포장하여 사용자에게 제공하는 것으로 보입니다. 반면 다른 RWA 프로토콜들은 대출을 받으려고 하는 주체마다 특색이 너무 다르다보니, 프로토콜에서 취급하는 대출들을 하나로 묶어 예치 상품을 만들기에 무리가 있었던 것으로 생각됩니다.

1.3 Tranche 구조의 디자인 시 고려사항

1.3.1 Junior tranche에 자금을 조성하는 것이 중요하다

위에서도 설명했듯이 RWA 토큰 담보 대출 프로토콜에서는 Borrower가 대출을 상환할 수 없게 되었을때 프로토콜도 미상환에 의한 피해에 노출되고, 이 vault들의 Lender들은 자신이 예치한 토큰들을 돌려받지 못할 수도 있는 피해가 발생합니다. Lender들은 주로 스테이블코인을 예치하고 비교적 자산 손실 위험성 없이 수익률을 얻으려고 하는 토큰 홀더들임을 고려할 때, Borrower의 파산에 의한 Lender의 손실 규모를 제한할 방법이 필요합니다.

현재 RWA 토큰 담보 대출 프로토콜에서는 junior tranche가 이 역할을 담당하고 있습니다. Junior tranche가 손실에 대한 버퍼 역할을 하기 때문에 일반 투자자들도 비교적 걱정을 덜어내고 RWA 프로토콜에 투자할 수 있는 상황이 만들어집니다. 즉, ‘무위험’이 아닌 RWA 토큰 담보 대출에서 junior tranche가 각 대출 포지션에 대한 보험 역할을 하고 있습니다. RWA 프로토콜들은 vault마다 존재하는 junior tranche가 junior tranche 예치자에게 충분한 수익률을 주고 있는지 모니터링하면서 junior tranche 예치금 규모를 확보하는 것을 신경써야 합니다.

1.3.2 Junior tranche와 Senior tranche 규모 비율을 잘 설정해야 한다

Junior tranche의 규모가 vault에서 일어난 대출 규모에 비해 너무 작으면 junior tranche 만으로 손실을 충분히 흡수할 수 없습니다. 그 점에서 junior tranche 규모가 너무 작으면 안 됩니다. 반대로 junior tranche의 규모가 너무 크다면 senior tranche에 분배되고 남는 이자액을 분배받는 junior tranche 구조상, junior tranche에 돈을 넣고도 충분한 이자 수익을 받지 못하게 될 가능성이 있습니다. 즉, junior tranche와 senior tranche의 규모 비율을 적절히 설정해야 합니다. 이 비율은 다음의 요소들을 고려해서 설정할 수 있습니다.

• Borrower의 미상환 확률 및 그에 대한 예상 손실액 — Vault에서 미상환이 일어날 가능성이 높을 수록 junior tranche의 규모를 키워야 합니다. Borrower의 미상환 확률을 파악할 때는 다음의 정보들을 활용해볼 수 있습니다: 해당 Borrower의 과거 대출 및 상환 히스토리, Borrower가 맡긴 RWA의 가격 안정성 및 처분 용이성, 전체적인 시장 상황
• 수익률 측면에서 junior tranche의 경쟁력 — Junior tranche를 통해 기대할 수 있는 이자 수익률은 senior tranche보다는 당연히 높아야 하고 다른 DeFi에서 스테이블코인으로 얻을 수 있는 이자 수익률보다는 웬만해서는 높아야 합니다. 그래야 토큰 홀더들이 senior tranche에 자산을 예치할 유인이 생깁니다.

RWA 토큰 담보 프로토콜에서 위의 요소들을 꾸준히 모니터링하면서 junior tranche의 규모를 유지할 수 있는지에 대해서 트랙킹하여야 합니다. Junior tranche 예치 수익률이 낮다면 프로토콜의 토큰을 junior tranche 예치자에게 보상해주는 형태로라도 보상을 주는 것이 바람직합니다.

1.4 케이스 스터디

1.4.1 디폴트 사례

2022년 RWA 프로토콜들의 vault에서 디폴트가 발생하였다는 뉴스들이 연달아 나왔습니다. 먼저 TrueFi에서 Blockwater Capital에 대출해준 $3.4M 규모의 펀드에 디폴트가 발생하였습니다. TrueFi에서 돈을 빌렸던 크립토 펀드인 Invictus Capital도 $1M 대출금을 정해진 날짜에 상환하지 못했습니다. Maple Finance에서도 크립토 펀드인 Auros Global에 빌려준 2,400 WETH에 대해서 제대로 상환받지 못하는 일이 발생했습니다. 그 외에도 Celsius, Alameda, Orthogonal Trading, M11 등의 주체들이 관리하는 vault에서 디폴트가 연달아 발생하면서 Maple Finance는 2022년 12월 당시 $54M 규모의 대출이 디폴트에 빠지기도 했습니다. Maple Finance 외에도 TrueFi에서 $4.4M, Centrifuge에서 $2.5M 규모의 디폴트가 발생하였습니다.

이때 발생한 디폴트들은 FTX 붕괴 때문에 일어난 경우가 많았습니다. 2022년 10월 이후에 발생했던 디폴트들의 공통점 중 하나는 Borrower가 크립토 펀드였다는 것이고, 이들은 FTX와 같은 거래소에 대출받은 자산을 넣는 경우가 많았습니다. 이들은 RWA 대출 프로토콜로부터 받은 대출금을 통해 마켓 메이킹, 차익 거래 등 자신의 전략을 실행하고 수익을 내서 대출금과 이자를 상환할 계획이었습니다. 하지만 FTX가 붕괴하면서 자신의 대출금이 거래소에 동결되어버리자 RWA 프로토콜에서 받은 대출을 상환하지 못하게 된 것입니다. FTX 외에도 Terra 스테이블코인 붕괴 때 큰 손실을 입어서 대출금을 상환하지 못하게 된 경우 (Invictus Capital)도 있습니다.

RWA 프로토콜에서는 vault에서 디폴트가 발생하였을 때 그 손실을 그 vault에 자금을 공급한 Lender들에게 나누어 분배합니다. 2022년 7월에 Babel Finance가 Maple Finance를 통해 빌린 $10M 규모의 대출이 디폴트 났을 때도, 디폴트에 의해 미상환된 금액이 vault의 Lender들에게 부과되었고 약 3.2% 수준의 손실이 발생하였습니다.

1.4.2 프로토콜 메커니즘 개선

Maple Finance가 작년의 디폴트들을 겪으면서 메커니즘을 변화시킨 방향을 보면 위에서 설명한 메커니즘 외에도 RWA 프로토콜이 추가적으로 고려할 수 있는 디폴트 리스크 관리 방법에 대해서 파악할 수 있습니다.

Borrower 다양화 — 작년 Maple Finance가 $50M가 넘는 규모의 큰 대출 미상환을 한번에 겪게된 이유 중 하나는 Borrower가 크립토 펀드에 집중되어 있었다는 것도 한 몫하고 있습니다. Borrower들이 모두 크립토 시장의 영향을 받는 플레이어다 보니, FTX 붕괴와 같은 사건이 터졌을때 많은 vault에서 동시다발적으로 미상환이 발생하였습니다. 프로토콜 입장에서는 이렇게 한번에 미상환이 발생해버리면 프로토콜에서 조성해놓은 트레져리를 통해서 미상환 내역을 복구시키는 데에도 부담이 생깁니다. Maple Finance도 이 문제에 대해서 인지하고 2023년부터는 대출 대상자를 더 다양화시키도록 방향을 설정했습니다.

Vault 관리자들의 권한 강화 — 이전까지는 Borrower의 미상환이 발생하더라도 vault 관리자들은 정해진 시일이 지나기 전까지는 디폴트 선언을 하지 못했습니다. 이 내용만 봤을때는 프로토콜이 정의해놓은 메커니즘에 따라 디폴트가 실행되는 것이기 때문에 문제가 아닐 수도 있습니다. 하지만 Borrower의 담보물을 청산시켜서 대출분을 강제적으로 갚도록 할 수 있는 방법이 없다는 특성상, RWA 프로토콜에서는 Borrower가 상환 능력이 없어졌다고 판단될 때는 최대한 빠르게 vault 자산을 동결시켜서 Lender의 자산을 최대한 보존하는 것이 필요합니다. 이 관점에서 Maple Finance는 vault 관리자가 판단했을때 Borrower의 상환 능력이 없어졌다고 판단된다면 vault 관리자가 즉각적으로 디폴트를 선언할 수 있도록 프로토콜을 수정하였습니다.

Vault 관리자의 인센티브 조정 — 2022년 디폴트 때 발생했던 문제는 vault 관리자 중에서 자신이 관리하고 있는 vault의 상황과 Borrower의 상환 상태에 대해서 정확한 정보를 공유하지 않은 경우도 있었습니다. 프로토콜의 로직 뿐만 아니라 프로토콜을 이용하는 Lender, Borrower, 관리자 간에 신뢰 관계도 중요한 RWA 프로토콜 특성상 vault 관리자의 이러한 행동은 디폴트에 의한 손실을 더욱 더 키울 수 있습니다. 이 점에서 vault 관리자가 vault를 만들때 그 vault의 junior tranche에 많은 자산을 예치하도록 강제하는 규칙도 필요합니다.

2. DeFi 프로토콜의 RWA 담보 대출 시장 진입

2022년 하반기부터 RWA 생태계에서 가장 많이 언급되었던 이슈 중 하나는 기존 DeFi 프로토콜 중에서 RWA를 취급하겠다고 발표한 프로젝트들이 하나 둘 등장했다는 것입니다. 그 대표적인 케이스가 MakerDAO와 AAVE입니다. 그 외에도 Frax Finance도 RWA 관련된 메커니즘에 대해서 활발하게 논의하고 있습니다. 이번 파트에서는 MakerDAO와 AAVE가 어떤 맥락에서 RWA를 도입하려고 했는지, 그리고 어떠한 형태로 RWA를 도입하고 있는지에 대해서 설명합니다.

2.1 MakerDAO

2.1.1 도입 목적

프로토콜의 안정적인 성장 — MakerDAO 커뮤니티의 주요 안건 중 하나는 언제나 DAI 발행량을 안정적으로 늘릴 수 있는 수단을 만들자는 것이었습니다. 2018년부터 스테이블코인을 운영하면서 MakerDAO가 느꼈던 문제 중 하나는 ERC20 토큰 담보 만으로는 DAI를 계속 늘릴 수 없다는 것이었습니다. 토큰 담보물만 받을 경우에는 DAI 발행량이 암호화폐에 대한 롱 수요에 너무 의존하게 된다는 것이 MakerDAO의 인식이었습니다. MakerDAO는 RWA 담보물들을 편입시켜서 RWA나 신용을 기반으로 대출을 받으려고 하는 주체들에게 DAI가 대출 수단으로서 유틸리티를 제공해줄 수 있기를 기대하고 있습니다. 이 전략 하에서는 MakerDAO가 더 이상 암호화폐 시장 상황에만 의존하는 것이 아니고, 실물 경제를 바탕으로도 DAI에 대한 수요를 만들 수 있습니다. 그 결과 DAI의 발행량이 더 안정적으로 성장할 수 있게됩니다.

수익 창출 — MakerDAO도 초반에는 DSR이라고 해서 프로토콜에서 제공해주는 DAI 예치 수수료를 통해 DAI에 대한 수요를 만들었습니다. 이 수요를 바탕으로 대출자들이 지불하는 이자를 프로토콜의 주요 수익으로 설정하기도 했습니다. 하지만 MakerDAO 커뮤니티는 얼마지나지 않아서 토큰을 통해 지급하는 yield는 높지 않거나 지속가능하지 않다는 것을 깨닫게 되었습니다. 반면 RWA에서 나오는 yield는 꽤 높으면서도 지속가능하다는 것에 집중하기 시작했고, RWA를 담보로 대출을 받으려고 하는 주체들에게 DAI를 직접 발행해주고 여기서 나오는 yield를 프로토콜의 주 수입원으로 만들려고 하고 있습니다.

2.1.2 도입 기준

MakerDAO는 특정 RWA에 대한 vault를 생성하거나 특정 Borrower에 대한 RWA 담보 대출을 진행할 때마다 커뮤니티 멤버들의 의견을 받고 결정을 내리고 있습니다. 이러한 결정을 내릴 때 MakerDAO 커뮤니티가 사용하기로 한 평가 기준은 다음과 같습니다.

• 확장성: 먼저 MakerDAO 입장에서 해당 RWA가 DAI 발행량을 충분히 늘릴 수 있을 정도로 발행량이 많고 시장 규모가 커야 한다고 제한하고 있습니다.
• 안정성: RWA가 DAI 발행에 대한 담보물로 이용되는 만큼 담보물은 가치가 안정적으로 유지가 되어야 합니다. 그 점에서 MakerDAO 커뮤니티는 해당 RWA의 가격 안정성이 충분히 있는지 그리고 처분할 수 있는 유동적은 시장에 충분히 형성되어있는지 파악합니다. 거기다가 이 때문에 MakerDAO의 안정성을 해칠 위험성은 없는지 평가합니다.
• 수요: MakerDAO에서 해당 RWA를 담보물로 받고 DAI를 발행해준다고 해도, 해당 RWA로 기존 금융권에서 대출을 받는 것이 이자 등 금융 비용 측면에서 더 낫다면 해당 RWA를 MakerDAO 담보물로 받아주는 것이 큰 의미가 없습니다. 그 점에서 MakerDAO 커뮤니티는 해당 RWA 소유자 입장에서 MakerDAO를 통해 대출 받는 것이 어떤 효용이 있을지, 즉 MakerDAO와 RWA 소유자가 서로에게 도움이 되는지 평가합니다.
• 규제 리스크: 그 외에도 RWA를 다루게 되다 보니 MakerDAO 팀은 해당 자산을 프로토콜에 편입하는 과정에서 규제나 법적으로 더 필요한 주체가 있는지, 기술적, 경제적, 규제적인 리스크가 더 있는지에 대해서도 고민합니다.

2.1.3 도입에 필요한 절차

그 외에도 MakerDAO는 RWA 도입할 때 필요한 과정들을 다음과 같이 정리해두고 있습니다.

• RWA 자산은 어떤 과정을 거쳐서 MakerDAO에서 취급가능한 자산으로 변환될 수 있는가? RWA를 프로토콜에서 담보물로 잡아두기 위해서는 이 자산을 토큰화시킬 수 있어야 합니다. 그리고 청산 등의 과정에서 처분을 할 수 있도록 하는 법적인 장치를 구상해두어야 합니다.
• DAI 대출자가 기존 금융권에서 같은 자산을 또 담보로 잡는것을 막을 수 있는가? 토큰화된 RWA의 법적인 권리와 실제 경제에서의 권리가 구분되어 있는 상황이기 때문에 Borrower가 자신의 RWA를 이용하여 MakerDAO로부터 대출을 받은 다음에 실제 금융에서 중복 대출을 받을 위험이 존재합니다. 이러한 일이 벌어진다면 Borrower가 RWA 프로토콜로부터 받은 대출을 상환할 가능성은 떨어질 수 밖에 없습니다. 그 점에서 MakerDAO는 자신이 담보로 받은 RWA를 이용해서 Borrower가 또 다른 대출을 받으려고 하는 것을 막으려 합니다.
• 가격 정보 등은 안정적으로 가져올 수 있는가? 오라클은 어떻게 디자인할 것인가? 청산 과정에서 담보 처분 방식에서 차이가 있다고 하더라도 RWA는 담보물로 작용하기 때문에 RWA의 가치는 Borrower의 상환 가능성에 여전히 큰 영향을 미칩니다. 그 점에서 MakerDAO는 해당 RWA 자산의 가치를 안정적으로 가져올 방법에 대해 고민하게 됩니다.

2.1.4 도입 현황

MakerDAO는 2022년 7월 Real World Finance Core 유닛을 만들었고 이들은 실제 금융에 대한 MakerDAO의 영향력을 높이는 것을 목표로 하고 있습니다. 프로토콜 팀은 이 유닛을 통해서 실제 금융에 있는 주체들에게 RWA 담보 대출을 진행해주고 있으며 그를 위한 vault를 지속적으로 생성하고 있습니다. 이 vault들은 대출을 필요로 하고 있는 Borrower에게 DAI를 직접 발행해주는 형태로 작동하고 있습니다. 다음 사이트에서 동작 중인 RWA vault들을 확인할 수 있습니다. 주요 vault들은 다음과 같습니다 (2023년 3월 기준).

MakerDAO에서 RWA 담보로 발행된 DAI의 양은 이제 $600M을 넘어섰고 특히 2022년 말부터 DAI 발행 속도는 빠르게 증가하고 있습니다. 특히 위에서 RWA009-A와 같은 vault는 정부 규제 하에 있는 은행에서 대출해주는 자금을 MakerDAO에서 직접 제공한다는 점에서 의미가 깊습니다. 프로토콜 수익 측면에서도 약 $650M 정도의 RWA 담보로 발행된 DAI가 2023년 1월 기준으로 프로토콜 전체 수수료 수익 중 75% 정도를 만들어내고 있을 정도로 프로토콜 수익 개선에도 큰 도움을 주고 있습니다.

이러한 배경하에서 MakerDAO는 단기 채권, 기관들의 신용, 에너지 생산 시설 등의 RWA를 담보로 DAI를 대출해주는 vault들을 지속적으로 검토하고 있습니다.

MakerDAO 커뮤니티에서는 RWA마다 거버넌스를 거쳐서 해당 자산을 취급할지 말지 결정하는 것이 비효율적이고 느리다는 의견이 나왔습니다. 그에 따라 MakerDAO에서는 Centrifuge (+ Tinlake)와 같은 RWA 토큰화 및 RWA 담보 대출 프로토콜과 파트너십을 맺어서 RWA 자산을 다루는 부분에서 필요한 절차는 RWA 프로토콜에서 맡도록 하고 있습니다. MakerDAO는 Maple Finance와도 파트너십에 대해 논의를 하고 있습니다. 여기서도 Maple Finance를 RWA 기반 담보 대출을 진행해주는 인프라로 활용하려고 하며, MakerDAO는 Maple Finance에 DAI를 발행해줌과 동시에 각 vault의 리스크에 따라 vault마다의 DAI 발행 한도, 기본 이자율 등의 파라미터를 조정하는 역할을 진행할 가능성이 높습니다. RWA 프로토콜과의 파트너십에서 MakerDAO가 상대 프로토콜에 기대하는 역할은 다음과 같습니다: 1) 대출자 온보딩 및 관리, 2) 법적인 절차 진행 혹은 법적인 구조 구성, 3) 디폴트에 대한 처리 절차 진행.

2.2 AAVE

2.2.1 도입 배경

GHO의 등장 — 2022년 7월, Aave 거버넌스 포럼에서는 Introducing GHO라는 안건에서 Aave 프로토콜 기반의 GHO라는 스테이블코인 발행 계획을 제안합니다. GHO는 타 스테이블코인과 마찬가지로 여러 종류의 자산군을 담보로 하지만, 암호화폐에 국한된 자산이 아닌, RWA나 credit score 등 서로의 관련성이 적은 다양한 자산군으로 함께 포함되어 있다는 점이 주목할 만 했습니다.

GHO 메커니즘에서는 단일 주체가 모든 담보를 관리하는 것이 아닌, facilitator라는 GHO token을 발행할 권한을 가진 주체가 등장합니다. Facilitator들은 GHO를 발행하기 위한 방법을 커뮤니티에 제안하며, 제안이 통과가 된다면 정해진 한도 내에서 facilitator가 제안한 방식에 의해 GHO를 발행할 수 있습니다. 재미있는 사실은 Facilitator는 GHO 발행 시 암호화폐를 담보로 하는 것을 고집하지 않아도 된다는 점입니다. 실제로 여러 자산군에 대한 담보를 포함하여 알고리즘 기반, 신용 기반 혹은 델타-뉴트럴 포지션 기반 등 각 facilitator가 원하는 방식으로 GHO를 발행/소각할 수 있으며, facillitator들이 다양화될수록 GHO의 가격 안정성이 높아지는 구조로 설계되어 있습니다.

DeFi에서 RWA의 중요성 — 2022년 11~12월, Aave 커뮤니티에서 RWA의 중요성에 대한 논의가 활발히 이루어지기 시작했습니다. Warbler Labs의 Punia는 <Helping Aave Think Through RWAs>에서 RWA가 Aave protocol에 크게 두 가지 방향에서 도움을 줄 수 있음을 언급했습니다. 첫번째는 암호화폐 외의 스테이블코인 담보의 다각화를 통한 안정성 확보이고, 두번째는 상대적으로 암호화폐를 이용한 레버리지보다 더 큰 규모의 자산을 활용해 GHO가 글로벌 스테이블코인으로 확장할 수 있는 기반을 다질 수 있다는 점입니다.

<Why RWAs are Important to DeFi> 에서는 DeFi가 crypto native에 집중하는 것 만으로도 어느 정도의(10x~) 성장은 이룰 수 있지만, 크립토 시장 규모의 한계는 명확히 존재하기 때문에 이를 넘어선 더 큰 성장(100x~)을 위해서는 RWA의 도입이 필요하다는 주장을 펼칩니다. 그래서 결국 DeFi가 메인스트림으로 진입하기 위해서는 TradFi의 시장 점유율을 빼앗아와야함을 주장합니다.

• DeFi와 TradFi를 전자상거래와 매장 거래의 비율 역전 현상에 비유하여 설명하는데, 인터넷이 활성화된 지금 사람들은 매장 거래보다 전자상거래를 선호합니다. DeFi와 TradFi도 마찬가지로 블록체인 기술이 발전하고 활성화될수록, 사람들은 TradFi보다 DeFi를 선호하게 될 것입니다.
• 금융은 사용자의 니즈가 항상 존재하는 분야로, 사람들은 항상 금융과 관련된 어플리케이션과 자금에 대한 유연성을 원하며 이는 보편적인 현상입니다. DeFi는 이러한 모든 면에서 더 나은 서비스를 제공할 수 있습니다.
• DeFi의 가시성과 상호운용성 덕분에 오히려 중앙화된 프로토콜보다 더 안전하고 변동성이 적을 수 있으며, 경제 시스템 전체에 더 나은 서비스를 제공할 수 있습니다.

MakerDAO에서의 성공 사례 — MakerDAO에서의 성공 사례는 Aave Protocol의 RWA 도입에 대한 주장에 더욱 힘을 실어줍니다. DeFi protocol에서 꾸준한 수익 흐름을 확보하는 것은 프로토콜 유지를 위해 대단히 중요합니다. <Outlining an RWA Strategy For Aave> 아티클에 따르면, 2022년 11월 기준 MakerDAO에서는 프로토콜 수익의 50% 이상을 RWA로부터 확보하고 있었음을 확인할 수 있습니다.

위 대시보드는 MakerDAO의 자산별 revenue의 비중 변화를 나타낸 것으로, 2023년 3월 기준으로 RWA가 차지하는 revenue가 50%를 훨씬 상회합니다. 시간이 지날수록 전체 revenue에서 RWA가 차지하는 비중이 점점 커지는 것으로 미루어 보았을 때, RWA가 생각보다 중요한 위치를 차지하고 있다는 것을 알 수 있습니다.

2.2.2 도입 효과 및 예상 결과

<Outlining an RWA Strategy For Aave> 아티클에 따르면, Aave가 GHO의 담보로 On-chain asset만을 포함할 때 발생할 수 있는 위험성은 다음과 같습니다.

• 시장 하락기에 청산 물량이 계속 발생할텐데, 관련 자산들의 시장 유동성이 부족할 경우 프로토콜에 부채가 쌓일 위험이 있습니다. 즉, 크립토 자산만 담보로 취급할 경우 프로토콜 디폴트 위험이 있습니다.
• 프로토콜의 유동성 부족은 결국 경제적인 공격이나 청산에 취약하게 만듭니다.
• 암호화폐 자산은 시장 상황에 굉장히 민감한데, 시장 하락기에서는 레버리지 수요가 낮아지기 때문에 대출 프로토콜의 현금흐름이 악화될 수 있습니다.

결국 Aave 커뮤니티에서는 RWA asset이 GHO의 담보 중 하나로 제공될 때 다음의 효과를 얻게 될 것으로 기대하고 있습니다. 이 전반적인 내용은 MakerDAO 커뮤니티가 RWA를 받기로 결정할 때 기대한 효과들과 전체적으로 일치하고 있습니다.

• RWA는 암호화폐 자산보다 안정적이고 변동성이 적기 때문에 리스크를 거시 경제의 흐름에 의존하게 되며, 보다 좁은 암호화폐 시장 자체의 변동성에는 강건함을 보입니다.
• RWA borrower의 자금 조달의 목적은 투기성 거래가 아닌 생산적인 비즈니스를 위한 경우가 많습니다. 이는 암호화폐 투기보다 훨씬 큰 규모이며 상승장과 하락장에 관계없이 일관성을 유지합니다.

2.2.3 Aave의 RWA 도입 전략

RWA는 기존의 암호화폐와 비교했을 때 그 특성이 완전히 다른 자산입니다. Aave 커뮤니티에서는 RWA를 어떤 방식으로 도입해야 하는지에 대한 논의가 활발하게 일어나고 있는데, <Outlining an RWA Strategy For Aave> 아티클에서는 DeFi의 요소 별로 구분하여 어떤 방식으로의 도입을 주장하고 있는지 살펴보았습니다.

• Asset types: 보다 덜 위험하고 수익률이 낮은 RWA를 먼저 도입하여 암호화폐 시장에서 RWA가 잘 동작하는지 확인하여 RWA facilitator에 대한 오랜 신뢰를 쌓은 후, 점진적으로 risky하고 high-yield를 제공하는 자산을 도입하는 방식을 고려해 보아야 함을 주장합니다. 자산군은 암호화폐 시장과 직접적인 상관관계가 없어야 하는데, maker, miner, DAO 등에 대한 대출을 제외하는 방식 등을 통할 수 있습니다.
• Debt Ceiling: 현실 세계에서 GHO를 fiat currency로 채택하는 데는 시간이 걸리므로 모든 차입자들이 초기에는 GHO를 기존의 fiat(USDC, USDT, USD, …)으로 바꾼다는 가정을 해야 합니다. 그렇기 때문에 할당된 부채 한도는 기존의 스테이블코인으로 판매하거나 상환 가능한 유동성에 비례해야 합니다. 궁극적으로 GHO가 USD에 soft-peg를 유지하는 것이 가치 유지에 중요하기 때문입니다. 이를 정리하면, 상당한 양의 GHO가 시장에 매도되어도 depeg되지 않을 정도의 debt ceiling을 유지해야 함을 주장합니다.
• Interest Rates: 현재 Aave의 이자율 모델은 RWA에 적용하면 안 되며, underwriting 및 TradFi와 유사한 딜을 기반으로 한 이자율 책정이 이루어져야 함을 주장합니다. Aave의 facilitator는 RWA의 이자율을 타 자산군과 다르게 설정할 수 있는 권한을 가지고 있기 때문입니다.

2.2.4 도입 현황

RWA market. 2021년 12월 28일, Aave는 Centrifuge와 합작하여 RWA의 토큰화를 위한 RWA market을 런칭하였습니다(https://rwamarket.io/). Centrifuge Tinlake의 TIN & DROP 모델을 Aave 서비스 내에서 제공하는 RWA market의 등장으로 예치자들은 안정적이고, 크립토와 상관관계가 없는 RWA 담보로부터 yield를 벌 수 있었으며, Centrifuge 발행자들은 Aave를 통한 대출로 크립토 시장을 대체 유동성 공급원으로 사용할 수 있게 되었습니다.

RWA market은 closed market이기 때문에, 예치자가 되기 위해서는 KYC 절차를 거쳐 검증이 완료된 사용자만이 투자자로 참여할 수 있습니다. 발행자(Centrifuge Issuer)는 그들의 자산에 대한 풀을 생성할 수 있으며, LP token은 Centrifuge Tinlake의 DROP에 해당합니다. 예치자(투자자)들은 USDC로 예치금을 스테이킹하여 해당 풀의 DROP을 구매할 수 있습니다.

출시 직후, RWA market의 size는 빠르게 증가하여 2022년 4월에는 $20M를 초과하기도 하였으나, 이후에 시장 하락기가 오면서 마켓 사이즈가 줄어들어 2023년 3월 기준 Total Market size는 약 $7.5M이 되었습니다. 하지만 다행히 자본의 디폴트는 발생하지 않았으며 프로토콜 자체는 원래의 의도대로 작동한다는 것을 보여주는 하나의 예시가 되었습니다.

RWA market의 운영을 통해 Aave에서는 RWA를 DeFi로 본격적으로 도입하기 위해 해결해야 할 중요한 몇 가지의 key challenge를 해결할 필요가 있다는 교훈을 얻었습니다.

• RA(Risk Assessment)나 Underwriting과 관련된 다양한 도메인 전문가들이 필요합니다.
• 대출자는 RWA 담보물의 지속 기간 및 유동성 등을 고려하여 전략을 신중히 고민해야 합니다. 이는 크립토와 같이 유동성이 높은 유형과는 본질적으로 다른 종류의 자산이기 때문에, 이와 대조적인 전략이 필요합니다.
• RWA의 펀딩은 Aave의 스테이블코인 유동성에 의존하는데, 종종 Aave 외부의 요인이 펀딩에 영향을 미칠 수 있습니다.

RWA facilitator. RWA market의 사례를 통해 DeFi로의 RWA 도입에 대한 가능성을 확인했다면, GHO의 발행을 위한 facilitator 중 하나로 RWA facilitator의 논의는 어떻게 진행되고 있는지 살펴보았습니다. 2022년 12월 기준으로, Aave 커뮤니티의 <Centrifuge’s Perspective of an RWA Facilitator for GHO> 제안에 의하면, Centrifuge는 GHO의 full-service RWA facilitator가 되려는 시도를 지속적으로 하고 있습니다.

앞선 글에서, RWA의 scaling을 위해 해결해야 할 여러 key challenge들이 있었습니다. Aave protocol에서 RWA facilitator에 기대하는 역할은 크게 다음과 같습니다.

• DeFi와의 결합성: RWA 담보가 온체인 생태계에 잘 통합되도록 하는 것을 의미합니다.
• 신뢰할 수 있는 인프라: RWA 담보와 관련된 중개를 수행하려면 건전한 법적 프레임워크 내에서 높은 수준의 투명성이 요구됩니다. RWA를 온체인 생태계에 성공적으로 온보딩시키기 위해서는 신뢰할 수 있는 전문적인 중개 프레임워크가 필요합니다.

Centrifuge는 현재 Centrifuge pool이 보유한 자산 기반의 인덱스 토큰을 개발 중에 있습니다. 전체 풀에 대한 인덱스로 해당 인덱스 토큰 구매자는 centrifuge의 자산들을 포트폴리오 형태로 구성해서 구매하는 효과가 생기는데, 이는 생태계 내의 전문가 집단(credit group)의 집단 지성들이 고민한 리스크 분산의 결과물입니다. RWA pool 역시 해당 인덱스의 포트폴리오 구성으로 포함될 수 있고, 이는 Aave GHO facilitator로써 가장 좋은 RWA 경험 사례를 제공하는 것일 수 있음을 주장하고 있습니다.

3. RWA 담보 대출 시장 현황 및 앞으로의 전망

지금까지 RWA 토큰을 취급하는 프로토콜들이 어떤 메커니즘을 사용하고 있는지, 그 메커니즘들은 어떤 이유에서 그렇게 설계되어있는지에 대해서 설명하였습니다. 이번 파트에서는 RWA 토큰을 다루는 프로토콜들의 현황에 대해서 간략하게 짚어보려고 합니다. 전반적인 대출 규모 추이부터 해서 각 프로토콜들은 어떤 상황인지에 대해서 다루겠습니다.

3.1 TVL 및 전체 대출액 추이

3.1.1 크립토 펀드 대상 대출의 성장과 축소

아래 그림은 RWA 토큰을 담보로 대출을 진행하고 있는 프로토콜들의 활성화된 대출 규모를 보여주는 그래프입니다. 2022년 이전을 보면 TrueFi가 RWA 담보 대출 대부분의 비율을 차지하고 있었습니다. 이는 TrueFi가 최초의 RWA 담보 대출 프로토콜로 등장했던 것도 영향이 있습니다. 그 이후에는 Maple Finance가 2022년 하반기까지 빠르게 성장하여서 Maple Finance와 TrueFi가 RWA 담보 대출 시장을 양분하고 있던 것을 확인할 수 있습니다.

이 당시 Maple Finance와 TrueFi가 대출을 진행해준 borrower 구성을 보면 MGNR, Auros capital, Folkvang trading, Alameda research 등 암호화폐를 기반으로 마켓 메이킹, 트레이딩을 진행하는 크립토 펀드들이 대부분이었습니다. 2022년 하반기까지는 암호화폐 불장에 따라 트레이딩 회사에서 더 많은 자금을 필요로 하게 되면서 Maple Finance와 TrueFi가 급격한 성장을 했던 것으로 보입니다.

하지만 2022년 하반기를 지나면서 Terra Protocol의 붕괴와 FTX 뱅크런과 같은 사건이 일어나면서 주요 크립토 펀드들도 큰 피해를 입었고 그에 따라 크립토 펀드를 대상으로 진행된 대출 규모도 확 줄어든 것으로 보입니다. 그에 따라 위의 그래프에서 Maple Finance와 TrueFi의 비중은 2023년부터는 사실상 없어졌습니다.

3.1.2 비크립토 펀드 대상 대출의 안정적인 성장

Centrifuge와 GoldFinch는 Maple Finance와 같은 폭발적인 성장을 보여주지는 못하였지만 그래도 2022년부터 꾸준히 성장하였고 작년 하반기의 큰 사건을 거치면서도 큰 피해 없이 전체 대출 규모를 유지해온 것으로 보입니다. 여기서 Centrifuge는 부동산 담보 대출, 화물 송장 담보 대출 등 다양한 자산군을 담보로 대출을 진행해주고 있고, GoldFinch는 개발도상국의 FinTech 회사나 부동산 회사를 대상으로 대출을 진행해주고 있습니다. 아래 그림은 Centrifuge의 섹터별 대출 상황을 보여주는 것으로 실제로 부동산, 개발 도상국, 기관 등 다양한 섹터에 골고루 대출을 진행해주고 있는 것을 확인할 수 있습니다.

Centrifuge와 GoldFinch는 자신들의 대출이 크립토 회사에 집중되어있지 않고, 비크립토 회사들 비중을 높게 가져갔기 때문에 작년에 큰 피해를 입지 않았던 것으로 보입니다. 이 점에서 지금도 Centrifuge와 GoldFinch를 통해 대출을 받으려고 하는 수요는 암호화폐 시장 상황과 상관없이 유지되고 그 점에서 안정적으로 성장을 해나가고 있습니다.

3.1.3 DeFi 랜딩 프로토콜에서의 RWA 담보 대출 증가

그 외에도, 위에서 설명드렸듯이 MakerDAO와 AAVE, FRAX 같은 스테이블코인 및 랜딩 프로토콜에서도 RWA 담보 대출에 활발하게 진입하고 있고, 프로토콜 내에서 RWA 자산의 비중을 서서히 늘려가고 있습니다. FRAX는 작년 6월부터 거버넌스 포럼 논의를 통해서 RWA 담보 대출 풀에 FRAX를 할당해두는 것에 대해서 논의를 하고 있습니다. 그리고 TrueFi, PropFi와 같은 회사와의 파트너십에 대해서 투표를 진행하기도 하였습니다. 아직 DeFi에서의 RWA 담보 대출 메커니즘을 도입한 지 얼마되지 않았지만 2023년 동안 이 분야의 성장이 얼마나 빠르게 진행될지 지켜보는 것도 의미있을 것 같습니다.

3.2 RWA 활용의 장점

3.2.1 실물 경제 플레이어들을 DeFi 생태계로 끌어들일 수 있다

아직까지는 DeFi, NFT와 같은 프로덕트들의 사용자 대부분이 예전부터 암호화폐를 소유하고 트레이딩을 해온 많지 않은 사람들에 집중되어있는 것이 사실입니다. 그 점에서 Web3 생태계를 더 키우려면 더 많은 유저들을 Web3 생태계로 온보딩시켜야 합니다. 이와 관련해서 Web2 X Web3 파트너십 등 다양한 시도들이 계속해서 진행되고 있고, RWA 토큰 담보 대출 또한 그 중 하나가 될 수 있습니다.

RWA 담보 대출을 통해서 기존 금융권에서는 제공해주지 못하는 가치를 투자회사나 기관들에 제공해주고 그들의 유동성을 DeFi 생태계로 끌어들인다면, 이는 Web3 생태계의 전반적인 규모를 다시 한번 키울 수 있는 원동력으로 작동할 수도 있습니다. RWA 프로토콜들을 통해서 여러 기관들을 Web3 공간으로 서서히 끌어들임으로써 블록체인이 새로운 금융 기술에 대한 인프라로서의 지위를 확보해나갈 수도 있다고 생각합니다. RWA 토큰을 DeFi 생태계로 도입시켜나가는 것은 사용자 저변을 넓힌다는 점에서 큰 의미를 갖습니다.

3.2.2 DeFi는 토큰 외의 다른 수익 창출 수단을 확보할 수 있다

앞에서도 설명했듯이, RWA 담보물을 통해서 블록체인 프로젝트들은 암호화폐 외의 다른 원천으로부터 발생하는 수익을 만들어낼 수 있습니다. 기존의 암호화폐 기반 인센티브는 시장 상황에 너무 많은 영향을 받았습니다. 거기다가 암호화폐 기반 인센티브는 유의미한 수준의 수익률을 주지 못하거나, 그 수익률을 지속하지 못한다는 문제가 있었습니다.

하지만 RWA에서 발생하는 이자 수익 등을 새로운 수익 수단으로 활용한다면 DeFi 프로토콜들은 자신들이 새롭게 발행하는 토큰들 외의 다른 수익 수단을 확보할 수 있습니다. 특히 RWA에 대한 리스크 파악과 관리만 잘 한다면 DeFi 관점에서도 매력적인 수익률을 얻을 수 있습니다. 실제로도 rwa.xyz 웹페이지를 보면 DeFi 프로토콜들이 취급하는 RWA에서 나오는 평균 이자 수익률이 10%인 것을 볼 수 있습니다. MakerDAO 수익 중 대부분이 RWA vault에서 발생한다는 것을 볼 때, RWA를 프로토콜로 잘 도입한다면 프로토콜은 자신의 수익 수단을 더 넓힐 수 있습니다.

3.2.3 DeFi 암호화폐 시장의 영향을 받지 않는 수요를 확보할 수 있다

DeFi이든 NFT든 도메인을 불문하고 블록체인 프로젝트들의 가장 큰 문제 중 하나는 모든 프로젝트들이 비트코인으로 대변되는 암호화폐 시장의 영향을 너무 크게 받는다는 것이었습니다. DeFi 랜딩 프로토콜의 경우 이 문제가 더 심각해집니다. 왜냐하면 DeFi 랜딩 프로토콜에 ETH, UNI 등 일반 토큰을 예치하고 랜딩을 하려고 하는 사람들은 보통 대출을 통해서 롱 포지션에 대해 레버리지를 치려고 하는 사람들입니다. 반대로 DeFi 랜딩 프로토콜에 스테이블코인을 예치하고 일반 토큰을 대출하려는 사람들은 숏 포지션을 대변하는 사람들입니다.

그러다보니 MakerDAO든 AAVE든 DeFi 프로토콜들을 보면 시장 상황에 따라 프로토콜의 규모가 급격하게 늘어났다가 줄어드는 것을 확인할 수 있습니다. 하지만 RWA를 소유하고 있는 주체들을 사용자군으로 포함한다면 이 프로토콜들은 암호화폐 시장의 영향을 비교적 덜 받는 수요를 확보할 수 있습니다. 그리고 이를 바탕으로 어느 정도는 프로토콜의 규모를 예측 가능하게 관리하면서 운영할 수도 있습니다.

3.3 RWA 활용의 단점 혹은 한계점

3.3.1 신뢰 문제가 발생한다

비용이나 트랜잭션 처리 속도 면에서의 장점 외에도, 중앙화된 누군가를 신뢰하지 않고도 블록체인과 스마트 컨트랙트를 통해서 기대할만한 결과를 얻을 수 있었다는 것도 DeFi를 통해서 얻을 수 있는 중요한 가치 중 하나였습니다. 하지만 RWA 토큰을 담보로 이루어지는 DeFi 활동들은 대부분 신뢰를 기반으로 작동하고 있습니다. 단적으로 Lender들은 자신의 돈을 예치할 때 vault 마다 존재하는 3rd party를 믿어야 합니다. 그러고 나서도 Borrower들이 정직하게 대출을 상환해나갈 것이라는 것도 신뢰해야 합니다.

지난 1년 동안 RWA 프로토콜에서 일어난 일들을 보더라도, vault의 3rd party가 정직하지 않게 행동해서 vault에서 디폴트가 발생하거나 Borrower가 미상환한 일도 발생했습니다. 이런 사례들을 볼 때 RWA 토큰과 관련된 더 확실한 법적 장치와 제도적인 기반이 이루어지기 전에는 이런 신뢰 문제가 계속해서 발생할 것이고, 그 이후에도 완전히 crypto-native한 DeFi에 비해서는 신뢰 문제를 어느 정도 감수하면서 이 프로토콜을 이용하게 될 가능성이 큽니다.

3.3.2 특정 유저들만 대출의 대상이 된다

RWA 대출 프로토콜에서는 Lender, Borrower, 3rd party 사이에 어느 정도의 신뢰가 필요하다고 언급했습니다. 이 점에서 RWA 토큰 담보 대출이 under-collateralized 대출을 목적으로 사용되는 것도 맞습니다. 하지만 주체들 사이에 신용이 필요하다는 점에서 아직까지는 RWA 대출 프로토콜을 통해서 대출을 받을 수 있는 사용자군은 특정 기관에 집중되어있습니다. Centrifuge, GoldFinch, Maple Finance 등의 프로덕트들을 보더라도 이 프로토콜을 통해 대출을 받거나 관리자 역할을 하고 있는 주체들은 어느정도 레퓨테이션과 전문성을 확보해놓은 기관에 집중되어있는 것을 알 수 있습니다. 이 점에서 아직까지는 일반인들도 RWA를 담보로 쉽게 대출받을 수 있는 시장은 형성되어있지 않습니다.

3.3.3 정말로 비용이 감소하는가?

스마트 컨트랙트를 통해서 금융 업무 중에 발생하는 여러 중재 비용을 줄일 수 있는 것은 사실입니다. 하지만 RWA 프로토콜들의 경우에는 RWA 토큰화, Borrower 및 RWA 리스크 파악 과정에서 별도의 비용이 발생합니다. 왜냐하면 해당 RWA에 대한 지식을 갖춘 전문가와 법적, 행정적인 업무를 처리해줄 주체들이 필요하기 때문이죠. 실제로 몇몇 프로토콜들은 vault 별로 특수목적회사(special purpose vehicle)을 설립하도록 하기도 합니다. 이 점에서 아직까지는 RWA와 관련한 여러 비용이 발생하는 것으로 보입니다. 이 한계점은 각 RWA에 대한 인프라가 갖추어지고, 자산 별 리스크 평가 기준도 어느 정도 확립될 때까지는 계속 발생할 것으로 보입니다.

3.4 RWA 프로토콜에 대한 개인 의견

RWA는 블록체인 생태계가 겪고 있는 한계점들과 전통 금융권에서 가지고 있는 여러 비효율적인 부분을 동시에 해결해줄 수 있다는 점에서 큰 가치를 가지고 있다는 것에는 동의합니다. 2023년부터 RWA와 관련된 여러 행정적인 가이드라인이 나오게 되면, RWA는 블록체인 시장으로부터 더 큰 관심을 받게 될 것이고요. 그 점에서 RWA 토큰들이 많은 관심을 받고 있는 것이며 앞으로도 이 시장은 커질 것이라고 생각합니다.

3.4.1 기존 금융권 혹은 Web3 제품과 다른 정체성에 대한 자각의 필요성

하지만 RWA를 다루는 프로토콜의 경우 기존의 DeFi나 블록체인 프로젝트들이 기반으로 하고 있는 철학과는 사뭇 다른 토대를 기반으로 하고 있습니다. 기존 Web3 제품들처럼 스마트 컨트랙트를 통해 모든 것이 처리되는 것이 아니라 어느 정도는 누군가를 신뢰하고 거기에서 발생하는 문제도 감수해야 한다는 점 때문입니다. 이는 Web3에 있던 사람들이 지금까지 봐왔던 기존의 Web3 프로덕트와 확연히 다른 특성으로 봐야하고, RWA를 다루는 프로토콜은 기존 금융 시스템과 Web3 프로덕트 그 사이 어딘가에 위치해있다고 생각합니다.

이러한 점에서 프로토콜이 RWA를 다룰 때는 자신의 서비스를 통해서 기존 금융권과 블록체인 생태계에 줄 수 있는 가치 뿐만 아니고, 자신이 왜 RWA를 다루려고 하는지 그리고 그 과정에서 발생할 수 있는 여러 문제 상황과 제약들을 기존 금융권과 블록체인 생태계에 있는 사람들 모두에게 명확하게 인지시키는 것이 필요합니다. 그리고 프로토콜은 운영해오면서 정보의 투명성과 중앙화된 요소로 인해 발생할 수 있는 문제들을 정확히 인지하고 이를 개선시키는 과정이 있어야 RWA 시장이 좀 더 성숙한 산업으로 발전할 수 있을 겁니다.

3.4.2 리스크 관리의 중요도

이 글에서 계속 언급하고 있지만 RWA를 다루는 프로토콜은 아직은 대출 프로토콜에 집중되어있습니다. 그리고 여기서 일어나는 대출들은 신용 대출의 형태를 하고 있습니다. 신용 대출 자체가 레버리지를 목적으로 일어나는 경우가 많다보니 무리한 확장과 투자를 하는 과정에서 언제든지 대출 시스템 자체가 불안정해질 수 있습니다. 특히 전통 금융과 같이 규제 하에 감시를 받으면서 대출이 일어나는 것도 아니고, vault마다 존재하는 3rd party의 자체적인 판단에 의해서 대출이 일어날 수도 있다보니 이러한 리스크는 프로토콜에 더 치명적으로 작용할 수도 있습니다.

아직까지는 대부분의 RWA 프로토콜에서 이러한 리스크에 대해서 완전히 대응할 수 있는 체계가 만들어지지 않았습니다. 그래서 프로토콜들은 현재 자신의 메커니즘에서 불가피하게 발생하는 (기존 Web3 제품 대비) 불투명한 정보 공개, 특정 주체의 행동에 의존해야 하지만 규제는 만들어져있지 않은 상황에 놓여져있습니다. 이러한 배경에서 각 프로토콜은 이러한 리스크를 어떻게 관리해야할 지 계속해서 신경써야 합니다.

About Us

Four Pillars is a global crypto research firm based in Seoul, consisting of the most influential blockchain researchers in Korea. Through robust research and governance skills, it helps various market players easily onboard to the blockchain industry by offering high-quality research articles while supporting protocols in their expansion into Korean and global markets.

Four Pillars Links

• Website (EN/KO)
• Twitter (EN/KO)
• Telegram (KO)

RWA 담보 프로토콜의 메커니즘 및 생태계 현황 was originally published in Four Pillars on Medium, where people are continuing the conversation by highlighting and responding to this story.

Author: 표정우

Audited By: 이태헌, 이동헌, 김홍욱

Intro

대부분의 AMM은 CPMM invariant을 활용한 pool로 구성되어 있고, 페어 자산의 비율은 동일하게 설정되어 있다. 자산의 성질이 어떤지에 관계없이 동일한 math를 사용하여 페어 자산 간 교환비를 제공하고 있는 경우가 대다수이다. 하지만 여러 자산들 중에는 두 자산 간 상관관계를 가지고 있는 경우가 있다. 이러한 경우 두 자산으로 CPMM invariant를 이용하는 pair를 구성하게 되면 자산 간 correlation이 전혀 반영되지 않아 시장가와 괴리가 생기게 된다. 이는 신뢰성 있는 DEX 구축을 방해한다.

Balancer에서는 pool을 구성하는 여러 자산들의 상관관계를 고려할 수 있도록 다양한 타입의 pool과 그에 맞는 invariant math들을 제공하며, customized pool을 제공하여 다양한 자산을 하나의 pool에서 관리할 수 있으며 pool 관련 파라미터를 조절 가능하도록 한다. 이번 아티클에서는 각 pool들에 적용되는 invariant math를 포함한 pool들의 특징 및 설명과 그 활용 예시에 대해 살펴보겠다.

Weighted Pool

보편적인 AMM은 두 자산의 비율을 50/50으로 설정하는 경우가 많다. Balancer의 Weighted Pool은 풀 생성자가 두 자산의 비율을 다르게 설정하여 만들 수 있도록 한다. 보통 80/20이나 60/20/20 풀을 많이 이용한다. 각 자산의 weighting이 다르고 pool에서 지원하는 자산 또한 3개 이상 가능하기 때문에, 스왑을 위한 invariant로 기존 AMM과는 조금 다른 weighted math를 사용한다.

Exposure control

DEX를 이용하는 사용자라면 누구나 비영구적 손실에 대해 고민하게 된다. 비영구적 손실은 pool에 초기 유동성을 공급했을 당시의 자산의 가격비가 변동되었을 때 발생한다. Pool에 유동성을 공급함으로써 얻는 governance yield 등을 제외하고 생각해본다면, 자산의 가격이 오를 때 디파이 프로토콜에 유동성 공급 후 얻을 수 있는 시세차익은 두 자산을 독립적으로 보유하는 것보다 적을 가능성이 높다.

특히, 특정 자산의 변동성이 매우 높다고 가정하면, 해당 자산을 포함한 pool이 안정적으로 유동성을 공급해주지 못할 가능성이 높다. 이러한 경우에 Weighted Pool을 사용하면 변동성 높은 자산의 weight를 줄임으로써 해당 자산의 가격이 pool에 미치는 영향을 기존의 방식보다 줄일 수 있다. 다음은 상대적인 가격 변동에 따른 Weighted Pool의 비영구적 손실에 대한 그래프이다.

Weighted Math

Weighted Math는 가격 상관관계가 없거나 크지 않은 자산 간의 스왑을 위해 설계되었다. 타 AMM과 마찬가지로, 각 자산의 가격에 영향을 주는 요소들은 pool balance, pool weights, 스왑하려는 토큰의 양 등이 있다. 또한 3가지 이상의 자산이 pool에 포함되는 경우를 고려하여야 한다.

Invariant of Weighted Math

Weighted Math의 invariant는 다음과 같이 정의된다.

• t는 token index에 해당
• B_t는 t번째 토큰의 balance에 해당
• W_t는 t번째 토큰이 pool에서 차지하는 normalized weight

invariant이므로 특정 pool의 V는 항상 동일한 값으로 유지되어야 한다. 실제 두 자산의 trade는 다음과 같은 수식에 의해 이루어진다.

outGivenIn, inGivenOut

토큰 i를 통해 토큰 o를 구매하려고 한다. pool에서 차지하는 토큰의 weighting을 각각 W_i, W_o, vault에 저장된 토큰의 balance가 각각 B_i, B_o, 지불하려는 토큰 i의 양을 A_i 라고 할 때, 스왑을 통해 수령할 수 있는 토큰 o의 양은 A_o이며, 다음과 같은 수식에 의해 계산된다.

마찬가지로, 스왑을 통해 받고싶은 토큰의 양(A_o)이 정해진 경우에는 다음 inGivenOut 수식을 통해 지불해야 하는 토큰 i의 양(A_i)을 계산할 수 있다.

Example

위 그림에서처럼 두 가지 경우를 예시를 통해 살펴보겠다. weighted pool에 공급된 토큰들의 수량이 다음과 같다고 가정하자.

• Token A: 100개
• Token B: 300개
• Token C: 200개

Case 1: A 50개를 B로 스왑하려고 할 때, 받을 수 있는 B의 양

사용자가 투입할 토큰의 양이 정해져 있는 경우이므로, outGivenIn 수식을 활용하여 사용자가 얻게 되는 B의 양을 계산하면 된다. pool에 포함된 A와 B의 balance는 각각 100개, 300개이며, weighted pool에서 차지하는 A와 B의 weight는 각각 0.3, 0.3으로 동일하다. 위 그림처럼 각각의 값을 식에 대입하면 받을 수 있는 B의 수는 100개이다.

Case 2: C 10개를 받기 위해서 지불해야 하는 A의 양

사용자가 받게 될 토큰의 양이 정해져 있는 경우에는 inGivenOut 수식을 활용하여 사용자가 pool에 지불할 토큰의 수를 계산할 수 있다. pool에 포함된 A와 C의 balance는 각각 100개, 200개이고, weight는 각각 0.3, 0.4이다. 이 값들을 대입하여 inGivenOut의 값을 계산해보면, 지불해야 하는 A의 양은 대략적으로 7개 정도가 된다.

Stable Pools

Stable pool은 각 자산 간의 가격변동이 거의 없는 스테이블 코인 및 합성자산들로 이루어진 pool을 구성할 때 사용한다. stable pool에 사용되는 invariant 역시 Curve protocol에서 제시한 StableSwap을 사용하며, pool의 비율이 크게 깨지지 않는 선에서는 거의 일정한 교환비를 제공한다. 이전에 BerryFi의 Curve 아티클에서 자세한 사항을 다루었기에, 본 아티클에서 Stable pool에 대한 자세한 설명은 생략하겠다.

MetaStable Pools

MetaStable pool은 Stable pool의 extension으로, stable pool이 일정한 가격을 유지하는 자산들의 AMM을 구성할 때 사용되었다면 metastable pool은 자산 간의 교환비가 일정한 AMM을 구성할 때 사용한다. 즉 자산 간의 상관관계가 매우 높지만 일정 가격에 peg되어 있지 않은 경우에 사용된다. MetaStable pool에 사용되는 math invariant 역시 StableSwap에 RateProviders를 추가하여 자산 간 교환비를 업데이트를 하는 방식으로 사용하게 된다.

Price Rate Cache를 통한 MetaStable Pool의 교환비 조정

MetaStable Pool은 RateProviders 컨트랙트를 통해 자산간의 교환비를 불러온다. 불러온 교환비에는 만료 시간이 있는데, 주기적으로 RateProviders 내에 있는 updatePriceRateCache()를 통해 pool 관리자가 수동으로 교환비를 업데이트할 수 있다. 따로 RateProviders의 컨트랙트 주소를 설정하지 않는 경우에는 자산의 교환비가 기본값인 1로 설정되어 StableSwap과 동일하게 동작한다.

Use case — wstETH/WETH 유동성 풀

MetaStable Pool을 사용한 대표적인 케이스가 바로 wstETH/WETH 풀이다. stETH는 Lido Finance에서 제공하는 Ethereum 2.0 staked Ether로써, 비콘체인의 검증인으로 참여하기 위해 스테이킹한 ETH를 유동화한 토큰이라고 생각하면 된다. Lido Finance에 대한 자세한 설명은 해당 아티클을 참고하자.

중요한 것은 stETH와 ETH는 가격적인 측면에서 강한 상관관계가 있다는 것이다. 이더리움 체인과 비콘체인이 merge되는 시점에서 stETH를 redeem함으로써 ETH를 받을 수 있기 때문에, 두 자산의 가격은 동일하지는 않지만 변동폭은 동일하거나 비슷하게 움직인다(적어도 Lido finance의 컨트랙트 결함 등의 이슈가 발생하지 않는 이상 서로 반대 방향으로 가격이 움직이는 경우는 거의 없다).

이러한 특성을 가진 자산의 교환에서 price impact를 많이 줄일 수 있는 방법은 Balancer에서 제공하는 MetaStable Pool을 사용하는 것이다.

Liquidity Bootstraping Pools(LBP)

기본적으로 Weighted Pool의 특성을 가지고 있는데, weighting이 time-dependent하게 동적으로 변하는 굉장히 특이한 pool이다. pool owner에게는 시작/끝의 weighting 값 설정 및 변화하는 시간의 설정, 스왑을 잠시 멈출 수 있는 권한 등이 주어진다. 이렇게 time-dependent weighting의 특성을 가진 pool을 활용하였을 때의 장점을 살펴보자.

Sell pressure를 방지하고 Fair Market을 형성하는 데 도움이 된다

토큰 IDO 런칭 초기에는 해당 토큰이 포함된 pool에서 수요로 인한 거래량이 급증하며, 이에 따라 시세차익을 얻기 위한 트레이딩 봇들이 많이 돌게 된다. 프로젝트의 미래를 보고 투자하려는 투자자는 단순 투기 목적으로 토큰을 구매하는 이들의 거래에 의해 합리적이지 않은 가격에 토큰을 구매하는 일이 많이 생긴다. LBP의 특성을 활용하면 투기 목적의 거래로 인해 토큰의 시세가 망가지며 프로젝트 투자자들이 손해를 보는 상황을 어느 정도 예방할 수 있다.

LBP를 활용해 초기의 프로젝트 토큰과 fiat 의 weighting을 90/10, 99/1 과 같이 프로젝트 토큰에 높은 weighting을 할당한 후, 시간이 지나면서 weighting을 50/50으로 맞추는 방식을 보통 많이 사용한다. 초기에 프로젝트 토큰의 weighting이 높으면, 해당 토큰의 시장가는 목표했던 가격에 비해 높게 형성된다. 따라서 투기 목적의 투자자는 초기에 많은 수의 토큰을 구매하기 망설여지게 되고, 시간이 지남에 따라 weighting이 조절되면서 토큰의 시장가는 점점 내려오게 된다.

프로젝트 토큰의 가격이 구매해도 좋다고 생각되는 적절한 시점이 되면, 추가적인 weighting 조정이 예고되어 있음에도 불구하고 시장 참여자들은 매수를 하게 되고, 결국 해당 토큰의 적절한 시장가가 결정되게 되는 것이다. 이렇듯이 LBP를 활용한 토큰 세일 방식은 AMM 런칭 초기의 투기성 매수를 방지하고 결국 토큰이 적절한 시장가로 유지되도록 도움을 주는 역할을 한다.

초기 자본이 적은 프로젝트에서 사용하기 적합하다

대부분의 프로젝트는 초기 자본이 적은 경우가 다수이다. 이러한 경우 pool을 만들기 위한 페어 자산을 많이 공급하는 것이 부담스러울 수가 있다(보통의 경우 페어 자산으로 스테이블코인이나 해당 블록체인의 native asset으로 구성한다). 그렇다고 적은 자산을 투입하여 유동성이 원활하지 않은 pool을 제공할 경우 스왑으로 인한 price impact가 매우 크기 때문에 장기적으로 프로젝트에 악영향을 끼칠 수 있다. 초기 풀에서 프로젝트 토큰의 weighting이 높으면, 일반적인 50/50 weighting pool에 비해 상대적으로 적은 페어 자산을 투입하여 유동성 공급이 가능하다.

Use cases — Copper

Copper라는 fair launch auction platform이 있는데, LBP를 사용하여 새로운 토큰의 initial offering을 제공한다. 펀딩의 참여자가 적을수록 해당 코인을 비싸게 사는 형태이고 세일 후반부에 살 수록 토큰을 싸게 사는 더치 옥션의 형태를 띄고 있다. 투자자는 세일에 늦게 참여하면 상대적으로 저렴한 가격에 토큰을 구매할 수 있으나, 세일 물량이 소진될경우 토큰을 구매하지 못하는 리스크가 있어 신중하게 토큰 세일에 참여하게 된다.

Additional Pools

Balancer의 pool을 이루는 base component는 위에서 소개한 weighted pool과 stable pool, time-dependent weighted와 관련된 LBP 정도이다. 이후에는 이 base component들을 기반으로 사용자의 목적에 맞게 조금씩 변형된 variant pool들을 소개해 보겠다.

Managed Pools

Managed Pools은 parameter의 제한을 많이 풀어서 자유도를 최상으로 끌어올린 형태이다. 기본적으로 Weighted Math를 사용하고, 해당 pool에 50개의 자산까지 추가할 수 있는 형태로 구성된다. 또한 LBP와 유사하게 time-based weight shifting을 지원하고, dynamic하게 weight를 조정할 수 있는 기능까지 포함한다. 이는 Managed Pool로 하여금 DEX 프레임워크의 역할을 수행할 수 있게 한다.

Feature Rich

Managed Pool은 아래와 같은 다양한 특징을 포함한다.

• Pool Manager(s)
• Management Fees (optional)
• Liquidity Provider Allowlists
• Up to 50 tokens
• Active Token Management — Add, Remove, Change token weights
• Circuit Breakers to protect from malicious/compromised tokens

Boosted Pools

Boosted Pool은 높은 자본 효용을 위해 사용자들에게 유휴 토큰들에 대한 거래 유동성을 외부의 프로토콜로 제공할 수 있게 해준다. 특히 스테이블코인에 대한 유동성을 매우 효과적으로 레버리징할 수 있다. Boosted pool에 대한 원리를 이해하기 위해서는 이를 구성하는 기본 컴포넌트인 linear pool과 phantom BPT에 대한 이해가 선행되어야 한다.

linear pool은 특정 자산을 목적에 맞게 변환한 토큰과 해당 자산이 페어로 이루어진 풀이다. Aave의 token-aToken pool이 바로 linear pool의 대표적인 예시이다. 기본적으로 linear pool의 토큰 쌍의 가격은 1대 1로 페깅되어 있다.

phantom BPT는 기존의 DEX에서 LP 유동성을 추가하고 제거하는 join/exit 기능을 전부 swap을 통해 수행하는 메커니즘을 뜻한다. LP에 대한 유동성을 공급하거나 제거할 때, 기존 방식은 LP token을 mint하거나 burn함으로써 유동성을 조절하였다. 하지만 phantom BPT는 LP가 생성될 당시에 모든 LP token을 발행하며, LP token을 pool 자체가 보유하고 있는 방식을 사용한다. 따라서 사용자는 LP 유동성을 추가하거나 제거하고 싶을때 swap을 통해 token과 LP token을 교환할 수 있게 된다.

Boosted Pool은 여러 linear pool들을 포함하는 nested한 구조로 되어 있고, Boosted Pool은 기존의 토큰을 직접 관리하지 않고 linear pool의 LP 토큰만을 관리하는 stable pool이다. 아래의 사진을 보면 조금 이해하기 쉽다.

그림 4는 Boosted Pool을 활용하여 Stable USD Pool을 구성한 것이다. 해당 풀에는 3개의 Linear Pool(DAI, USDC, USDT)이 포함되어 있고, 각각의 linear pool은 해당 token-aToken의 페어로 구성된 별도의 pool이 존재하며, linear pool마다 bb-a-token(LP token)이 존재한다(phantom BPT 방식). 결국 Stable USD Pool이 직접 관리하는 토큰은 각 linear pool의 LP token(bb-a-DAI, bb-a-USDC, bb-a-USDT) 3종류이며, 사용자는 결국 각각의 linear pool을 통해 그들의 스테이블코인과 bb-a-token을 스왑하여 사용하게 된다. 사용자들이 해당 pool을 활용하여 스테이블코인을 스왑하는 과정은 다음과 같다.

case: USDC를 DAI로 바꾸고 싶은 경우

1. Linear USDC Pool에서 USDC → bb-a-USDC로 스왑(phantom BPT이기 때문에 token-LP token 간 스왑이 가능)
2. Stable USD Pool에서 bb-a-USDC → bb-a-DAI로 스왑
3. Linear DAI Pool에서 bb-a-DAI → DAI로 스왑

Conclusion

이번 아티클에서는 weighted pool과 stable pool, MetaStable Pool, time-dependent한 LBP, managed pool, boosted pool 등 Balancer에서 기본적으로 제공하는 pool에 대한 설명과 그 예시를 살펴보았다. Balancer에 있는 pool을 잘 활용한다면 온체인 상에서 우리가 생각할 수 있는 대부분의 자산 포트폴리오를 구성할 수 있으며, 다양한 자산에 대한 pool을 사용자에게 제공함으로써 디파이 서비스에 대한 기획을 할 때 거래에 대한 제약을 크게 신경쓰지 않고 조금 더 자유롭고 폭넓은 사고가 가능할 것으로 생각된다.

[Balancer] 2. Balancer의 Pools was originally published in BerryFi on Medium, where people are continuing the conversation by highlighting and responding to this story.

Author: 표정우

Audited By: 이태헌, 이동헌, 김홍욱

Intro

Balancer는 DEX 상에서 자동화된 포트폴리오 매니지먼트를 수행하게 하기 위한 디파이 프로토콜로, Fernando Martinelli가 처음 제안한 프로젝트이다. Balancer의 pool은 기존의 AMM 모델과 다르게 세 종류 이상의 다양한 자산으로 이루어진 pool을 구성하고, 유동성 제공에 따른 swap fee와 같은 파라미터들을 조절할 수 있다. 또한, weighted pool을 사용하게 되면 LP pool을 구성하는 자산의 비중이 50/50이 아닌 80/20, 90/10 등 유동성 공급자가 원하는 비율의 설정이 가능하다는 특징을 가지고 있다.

분산환경에서 Balancer의 역할은 전통 금융시장에서의 자동화된 인덱스 펀드와 유사하다. 다만, 인덱스 펀드는 구매자들이 수수료를 지불하면서 브로커에 의해 포트폴리오 리밸런싱이 이루어지는데 반해 Balancer pool은 trader들의 스왑에 의해 자동적으로 포트폴리오 리밸런싱이 이루어지면서 오히려 스왑에 대한 수수료를 사용자들에게 혜택을 줄 수 있다.

Balancer Protocol의 핵심은 결국 디파이 환경에서의 자유로운 자산관리 시스템을 구축할 수 있다는 데 있다. 풀을 구성하는 자산의 종류부터 시작해서 자산의 구성 비율, swap fee에 대한 구조 등 DEX를 구축하는 데 필요한 대부분의 parameter를 LP가 커스터마이즈할 수 있기 때문에 Balancer를 활용한 DEX의 구축은 큰 무기가 될 것이다.

Balancer의 Product: The Vault

Balancer에서 제공하는 product들은 Vault, Weighted Pool, Smart Order Router 등 여러 가지가 있지만, 이번 글에서는 Balancer의 핵심 프로덕트 중 하나인 Vault 모듈과 Vault를 구성하고 있는 핵심적인 기능들을 살펴보고, 이를 통해 어떻게 트랜잭션 수수료를 낮추고 슬리피지 등의 요소를 줄였는지에 대해 코드 분석과 함께 설명하겠다.

Token management와 Pool logic을 구분

기존의 DEX들은 LP pool이 소유하고 있는 토큰이 pool contract에 직접 보관되어 있었다. 그래서 pool의 swap method를 실행하면 pool contract가 보유한 자산을 바꾸어주는 방식으로 스왑이 수행되었다.

하지만 Balancer의 Vault 구조에서는 token management와 pool logic을 구분하였다. Balancer가 소유하고 있는 모든 token은 Vault에서 일괄적으로 관리하고, pool contract는 vault contract와 분리되어 오직 swap, join, exit 등 AMM의 자산 스왑과 관련된 수학적인 계산만을 수행하는 역할을 담당한다. 그래서 pool contract는 기존의 DEX pool contract에 비해 구조가 많이 단순화되었다. 누군가가 trading system에 대한 새로운 아이디어가 있으면, 해당 토큰의 유동성이 작다고 걱정할 필요 없이 누구나 커스텀 풀을 만들어서 Balancer가 가지고 있는 유동성을 활용해 Liquidity Pool을 구성할 수 있다.

BatchSwap: Gas fee optimization

Multi-hop trading은 여러 번의 token transfer를 통해 토큰 스왑을 수행하는 방법을 말한다. 동일한 메인넷 네트워크 상에서 사용자가 원하는 토큰과 보유한 토큰의 pair LP가 구성되어 있지 않거나 그 유동성이 부족하여 price slippage가 크게 발생할 가능성이 높은 경우에 빈번하게 사용된다.

Vault에서는 multi-hop trading에 BatchSwap이라는 방법을 사용한다. Vault는 단일 contract에 모든 토큰을 소유하고 있기 때문에, multi-hop trading을 수행하는 과정에서 타 DEX와 다르게 실제 transfer를 수행하지 않는다. 대신 스왑 수행 이후의 각 자산의 delta 값을 Vault contract의 _internalTokenBalance라는 스토리지 변수에 반영함으로써 token transfer의 횟수를 최소화한다. 좀 더 자세히 설명하면, ERC20 토큰의 전송은 해당 토큰의 컨트랙트 주소를 call한 후 transfer를 수행하기 때문에 가스비의 소모가 크다. 하지만 Vault contract 내부에 선언된 스토리지 변수(internal balance)를 조정하는 방식을 사용하면 contract call을 통한 토큰의 직접 transfer 방식에 비해 가스비 소모가 적다. 이는 기존의 방식에 비해 높은 gas efficiency를 보여준다.

Security

모든 token을 단일 Vault contract에 보관하고 각 LP pool의 balance를 기록해놓는 Vault의 특성 상, vault contract는 pool contract와 독립적으로 동작하게 된다. 이러한 독립성을 유지하는 것은 크게 2가지 장점이 있다.

1. custom pool을 형성하여 fund draining을 시도하는 등의 악의적인 행위를 막을 수 있다.

DEX는 블록체인 상의 permissionless system 위에서 작동하는 어플리케이션이다. 기존의 DEX처럼 pool 별로 유동성 및 자금이 관리되면 악의적인 목적을 가진 누군가 페어 토큰의 시장 가격과 다른 비율로 custom pool을 구성할 수 있다.

예를 들어 BTC의 시장가가 100$, ETH가 50$이라면 초기 custom pool을 생성할 때 토큰의 수를 1:2 비율로 설정해야 한다(50/50 weighting 기준). 하지만 pool 생성자가 이 비율을 벗어난 형태로 구성할 경우 해당 pool을 통해 스왑을 사용하는 사용자는 시장가격과 다른 가격에 토큰을 스왑하는 것이 되어 큰 손해를 볼 수 있고, 반대로 custom pool 생성자는 큰 금전적인 이득을 취할 수 있다.

하지만 Balancer를 활용하면 BTC/ETH의 토큰의 수를 1:4 비율 등 시장가의 비율과 다르게 임의로 설정하는 것이 어렵다. 예로 기존의 DEX pool의 같은 경우 pool 내에서 자금을 관리하기 때문에 소액을 활용하여 BTC/ETH의 토큰의 양을 1:100의 초기 구성으로 설정하면 사용자가 실수로 해당 pool을 통한 스왑을 진행하는 등의 경우가 발생할 수 있다. Balancer는 AMM의 수식을 볼트 전체가 보유한 자산을 이용하여 계산하기 때문에 애초에 토큰의 수를 1:100 으로 구성할 수 없다. Vault에서 보유하고 있는 BTC와 ETH의 양이 충분할 경우, 시장가격이 이미 전부 반영되어 있기 때문에 토큰의 가격을 조작하는 것이 불가능하기 때문이다. 이는 pool 단위에서 자산을 관리하는 것이 아니라 Vault에서 자산을 모아서 관리하기 때문에 가능한 Balancer만의 장점이라고 볼 수 있다.

2. pool의 유동성이 분리된 pool을 통해 운영하는 것보다 커서 price slippage로부터 강건하다.

pool 생성자가 100개의 A token을 보유하고 있고, A/B, A/C 두 개의 페어 풀에 유동성 공급을 할 경우 기존의 DEX에서는 보유한 A를 페어 풀에 적절한 비율(ex. A/B에 A 토큰 50개, A/C에 A토큰 50개)로 나누어 공급하였다. 이러한 방법은 보유한 A token에 비해 유동성의 규모가 축소되는 결과를 낳는다.

Balancer에서 pool은 실제 토큰을 보유하지 않는 virtual pool이기 때문에 A/B, A/C 두 개의 풀에 모두 100개의 A 토큰에 해당하는 유동성을 공급할 수 있다.

Flashloan

Vault에서는 플래시론을 지원한다. 플래시론이란, 단일 트랜잭션을 통해 무위험 차익을 얻고자 하는 차익거래자가 자본이 없는 상태에서도 무담보로 특정 자산을 대출받은 후, LP의 비율이 달라져 있는 DEX에서의 스왑을 통해 차익을 얻은후 바로 상환하는 방법이다. 플래시론을 직접 실행하는 차익거래자는 해당 행위를 통해 수익을 얻을 수 있고, 디파이 프로토콜은 플래시론을 지원함으로써 LP를 구성하는 자산들의 불균형을 해소하여 보다 정확하고 균일한 가격을 제공할 수 있다는 장점이 있다.

컨트랙트 분석을 통한 batchSwap 메커니즘 파악

batchSwap과 관련된 컨트랙트 코드 분석을 통해 자세한 batchswap의 메커니즘을 확인해보았는데,특히 Vault의 internal balance를 활용하여 여러 번의 스왑에 대한 gas fee를 잘 절약하는지에 대해 중점적으로 살펴보았다.

Swapkind에 따라 Given-in, Given-out을 구분

batchSwap은 여러 건의 연속적인 스왑이 포함되며, 이를 multi-hop swap이라고 부른다. 스왑의 종류는 열거형 변수인 Swapkind kind값에 따라 given-in swap과 given-out swap 두 가지로 구분된다.

• GIVEN_IN: 사용자가 pool로 보내려고 하는 A 토큰의 양을 고정(주어진 값)하고, 이에 따라 사용자가 받게 될 B 토큰의 양이 계산(계산된 값)된다.
• GIVEN_OUT: 사용자가 pool로부터 받게 되는 B 토큰의 양을 고정(주어진 값)하고, 이에 따라 pool이 보내게 될 A 토큰의 양이 계산(계산된 값)된다.

주어진 값은 이전 스왑의 결과로 얻게 되는 토큰의 양과 같이 이미 결정된 값을 의미한다. 계산된 값은 pool contract의 수식에 의하여 계산된 값으로, vault의 internal balance에 적용하기 위한 값이다.

multi-hop swap에서 In, out에 해당하는 토큰의 양이 주어진 값인지 계산된 값인지를 구분하는게 중요한 이유는 스왑 경로에 여러 종류의 intermediate token들이 포함될 수 있기 때문이다. Targeted token이 아닐 경우 token transfer를 수행해야 할 필연적인 이유는 없고, 무의미하게 token transfer를 수행하면 많은 가스비가 발생하게 된다. 따라서 intermediate token과 관련된 스왑의 경우는 수량에 대한 계산을 통해 Vault의 internal balance만을 조정하고 실제 token transfer는 수행하지 않는다. 해당 부분에 대한 설명은 아래에서 BatchSwapStep 구조체를 설명할 때 더 구체적으로 설명하겠다.

batchSwap을 이해하기 위한 자료형 및 구조체

batchswap을 이해하기 위한 상태 및 구조체는 다음과 같다.

1. SwapKind:연속적인 스왑에 대한 특성이 어떠한지를 나타내는 것으로, GIVEN_IN과 GIVEN_OUT 두가지로 나뉜다.
2. BatchSwapStep: 스왑에 대한 정보를 포함하며, BatchSwapStep에 포함된 필드는 다음과 같다.

poolId: pool의 ID

AssetInIndex: assets에서 tokenIn ERC20의 contract address가 포함된 인덱스

AssetOutIndex: assets에서 tokenOut ERC20의 contract address가 포함된 인덱스

amount

kind 값에 따라 amount가 의미하는 바가 다르다. kind가 GIVEN_IN인 경우, amount는 tokenIn의 주어진 값이며, 스왑 과정에서 tokenOut의 계산된 양을 구하게 된다. GIVEN_OUT일 경우는 그 반대로 amount = (tokenOut의 주어진 값)이 되며, 스왑 과정에서 tokenIn의 계산된 양을 구한다.

caller가 swaps.length가 2 이상인 multi-hop swap을 실행할 경우, swaps[0]을 제외한 나머지 element의 amount 값은 전부 0으로 할당시키게 된다.(GIVEN_IN swap의 경우)

batchSwap 과정에서(정확히는 _swapWithPools()에서) amount에 0이 할당된 경우의 step은 이전 BatchSwapStep의 calculated amount로 재할당된 후 balance 계산이 이루어진다.

userData: 해당 필드는 Vault에서는 무시되나, 추후에 Pool의 onSwap hook을 수행하는데 전달되어 swap의 기능을 확장하는데 사용된다.

3. FundManagement: Swap fund를 vault internal balance를 통해 집행할지 token transfer로 집행할지에 대한 내용이 담겨 있다.

address sender, recipient: 보내는 주소와 받는 주소

bool fromInternalBalance: asset을 보낼 때 자산을 sender의 Vault internal balance에서 보낼 것인지 아니면 직접 token transfer를 통해 보낼 것인지 선택하는 필드이다. True일 경우 vault에서 스왑을 집행하게 되며 가스비가 적게 든다는 장점이 있다. 혹시 보내는 토큰의 양이 sender의 vault internal balance보다 많을 경우 sender의 지갑으로부터 차액에 해당하는 토큰이 추가로 스왑된다.

bool toInternalBalance: fromInternalBalance와 반대로, asset을 받을 때 recipient가 Vault internal balance로 받을지 직접 token transfer로 받을지를 선택한다. True일 경우 Vault로 송금받는다.

batchSwap의 argument

• SwapKind kind: 연속적인 스왑에 대한 특성이 어떠한지를 나타내는 것으로, GIVEN_IN과 GIVEN_OUT 두가지로 나뉜다.
• BatchSwapStep[] memory swaps: 연속적인 스왑 각각에 대한 정보를 array 형태로 제공한다.
• Asset[] memory assets: batchSwap에 사용되는 모든 asset의 ERC20 contract address가 담긴다.
• FundManagement memory funds: Swap fund를 vault internal balance를 통해 집행할지 token transfer로 집행할지에 대한 내용이 담겨 있는데, 모든 swap에 통용되는 변수이기 때문에 array 형태로 제공하지 않는다.
• int256[] memory limits: 스왑이 허용되는 토큰의 최대 양이다. 급격하게 변하는 시장과 여러 MEV 공격으로부터 사용자를 보호하기 위해 스왑에 포함된 모든 토큰에 대하여 limits 라는 변수를 할당하여 이동 가능한 토큰의 수의 최댓값을 설정해 놓았다.
• uint256 deadline: 지정한 시간이 지나면 swap을 revert한다.

batchSwap 함수의 메커니즘

batchSwap의 흐름은 크게 세 단계로 구분하여 살펴볼 수 있다.

1. _swapWithPools()를 통해 스왑에 포함되는 모든 자산의 변화량을 assetDeltas에 저장한다.
2. 자산별로 delta값이 주어진 limits을 초과하지 않는지 체크한다.
3. delta > 0이면 funds.sender로부터 delta 만큼 해당 자산을 전송받고, delta < 0이면 funds.recipient에게 (-delta)만큼의 자산을 보낸다.

1. _swapWithPools()를 통해 스왑에 포함되는 모든 자산의 변화량을 assetDeltas에 저장한다.

_swapWithPools()의 역할은 BatchSwapStep[] swaps 값을 이용하여 swaps.length 번의 연속적인 스왑을 수행하는 것이다. swaps.length가 1인 경우는 타 AMM에서 사용하는 단일 스왑과 다른 점이 없다. 하지만 length가 2 이상인 경우는 multi-hop swap으로, 스왑의 target asset과 무관한 intermediate token이 batchSwap 과정에 포함되게 된다.

해당 함수 내부에서는 swaps[i].amount의 값을 확인하는데, 이것이 0으로 할당되어 있으면 swaps[i]을 multihop swap과정에서 intermediate token이 포함된 거래로 간주한다. 그래서 swaps[i-1]에서의 계산된 값을 swaps[i].amount로 할당하게 된다. 이유는 위에서 설명하였듯이, 스왑의 종류가 GIVEN_IN swap이라고 가정하였을 때 바로 앞 단계 스왑에서의 tokenOut amount는 계산된 값이고, 스왑은 sequential하게 실행되므로 이것이 곧 현재 단계 스왑에서의 tokenIn amount가 되기 때문이다.

2. 자산별로 delta값이 주어진 limits을 초과하지 않는지 체크한다.

Vault의 자산을 보호하기 위한 조치로, 간단한 _require() 함수를 통해 처리한다.

3. delta > 0이면 funds.sender로부터 delta 만큼 해당 자산을 전송받고, delta < 0이면 funds.recipient에게 (-delta)만큼의 자산을 보낸다.

assetDeltas는 모든 assets에 대해 계산한 delta의 array이다. 이를 iterate하면서 다음을 확인한다:

• delta 값이 0 초과일 때: funds.sender가 delta에 해당하는 ERC20 혹은 WETH를 보낸다
• delta 값이 0 미만일 때: funds.recipient가 -delta에 해당하는 ERC20 혹은 WETH를 받는다

delta가 0보다 클 경우, _receiveAsset() 내부 함수를 이용해 funds.sender에서 vault로 자산이 이동하고, delta가 0보다 작을 경우에는 _sendAsset()을 이용해 vault에서 funds.recipient로 자금이 이동한다. _receiveAsset()의 내부를 한번 살펴보자.

_receiveAsset()에서는 해당 스왑이 internalBalance를 이용하는지를 체크하고, sender가 delta 이상의 자산을 vault에 보유하고 있으면 이를 internal balance에서 차감한다. 만일 delta 값이 sender가 vault에 보유한 internal balance보다 크다면 나머지를 ERC20의 transfer 기능을 활용하여 직접 전송하게 된다.

_sendAsset() 역시 비슷한 메커니즘으로 작동한다.

마치며

본 아티클을 통해 알아본 Balancer의 특징을 요약하면 다음과 같다.

• Balancer는 자산 관리를 위한 LP Pool을 구성하는 자산의 종류 및 그 비율을 자유롭게 조절하고, liquidity mining을 통한 수수료 및 스왑에 대한 수수료도 관리자에 입맞에 맞게 설정 가능하기 때문에 DeFi 시스템 구축을 위해 효과적이고 유연한 building block을 제공한다.
• Vault contract에서 모든 자산이 관리되며, pool contract는 AMM을 위한 수식을 적용하기 위한 것이지 실제 자산이 들어있지 않는 virtual pool이다.
• batchSwap을 활용하면 multi-hop swap을 수행할 때 vault의 internal balance를 조정하는 방법을 통해 token transfer를 줄임으로써 수수료를 최소화할 수 있다.

이번 아티클에서는 Balancer에 대한 전반적인 설명과 주요 product에 대한 소개, 그 중에서도 Vault에 대해 집중적으로 다루어 보았다. 다음 아티클에서는 Pool에 대해서 자세히 다루어보도록 하겠다.

[Balancer] 1. Vault와 batchSwap 컨트랙트 분석 was originally published in BerryFi on Medium, where people are continuing the conversation by highlighting and responding to this story.

Author: Jungwoo Pyo

Audited By: 태헌이, 이동헌

AMM(Automated Market Maker)은 DEX(Decentralized Exchange)에서 사용하는 화폐 교환 프로토콜이다. LP pool(Liquidity Provider pool, 줄여서 LP로 통칭)에 교환을 하기 위한 두 자산을 예치하면, LP에서 정한 가격 결정 알고리즘에 의해 두 자산간의 교환이 가능하다.

유니스왑에서 처음 constant-product invariant를 적용한 DEX를 출시하였다. constant-product invariant는 단순히 공급된 두 자산의 양의 곱이 항상 일정해야 한다는 가격 결정 알고리즘이다. 이는 간단하면서도 매우 직관적이라, 현재 대부분의 DEX가 사용하는 가격 결정 알고리즘이 되었다.

constant-product based AMM의 한계

DEX LP를 통한 자산 간의 스왑은 중앙화된 거래소의 시장가를 활용하는 오라클을 사용하지 않고 실제 시장가와 관계 없이 거래하는 LP의 화폐 비율만을 고려하여 거래된다. 기존의 constant-product invariant를 사용하는 AMM에서 DEX LP를 구성하는 자산의 가치가 변동성이 있는 경우에는 별 문제가 되지 않는다.

하지만 가치의 변동성이 적어야 하는 스테이블코인 간의 거래에서 이러한 문제는 큰 price slippage를 야기하게 된다. 대부분의 DEX에서 constant-product invariant를 이용하기 때문에 발생하는 문제이다.

Uniswap이나 Bancor, Kyber network와 같은 대부분의 DeFi market에서는 LP를 통한 스왑 시 constant-product invariant를 기준으로 사용하게 된다. constant-product invariant는 스왑 이전과 스왑 후 해당 pool을 구성하는 두 코인의 수의 곱이 일정해야 한다는 가격 결정 방식이다.

constant-product invariant를 사용하는 것은 대부분의 가치가 변하는 자산에게는 적합한 방법일 수 있으나, 가치의 변동을 최소화해야 하는 스테이블코인에서는 적절하지 않다. LP에 막대한 유동성이 공급되어서 스왑을 수행해도 pool의 비율을 크게 변동시키지 않는 경우에는 상관없지만, 그렇지 않은 경우는 큰 price slippage가 발생하게 되기 때문이다.

Curve Protocol에서의 StableSwap

AMM-based market에서 스테이블코인의 용처는 다양해지고, 점점 사용이 증가하는 추세이다. 그러나 스테이블코인들을 다른 스테이블코인으로 변환하는 과정에서 가격 안정성과 유동성 측면에서 문제가 있어왔다. 디파이 프로토콜을 활용하는 사용자 입장에서는 스테이블코인의 가치 차이가 클수록 lending과 같은 기능을 사용하거나 다양한 종류의 디파이를 사용하는데 제약이 발생한다. 예를 들어, 사용자가 보유 중인 DAI를 예치하고 이를 담보로 USDC를 빌려 추가적인 수익 창출 활동을 하려고 한다. 해당 시점에서 DAI와 USDC의 가격 차이가 크게 발생한다면, 사용자는 DAI로 USDC를 스왑하는것을 부담스럽게 생각하게 되고 다양한 프로토콜의 사용이 제한될 것이다.

AMM 상에서 스테이블코인 간의 스왑 슬리피지를 최소화할 필요성이 대두되었고, Curve는 외부 오라클을 사용하지 않고 스테이블코인 간의 스왑을 용이하게 하는 StableSwap이라는 방식을 제안했다.

스테이블코인 간 스왑시 조금의 손실도 발생하지 않는 이상적인 방식은 무엇일까? 바로 constant-sum invariant(x+y=const)를 적용하는 것이다. 이것은 LP를 이루는 두 코인의 가치가 동일하고 변하지 않는다는 가정이 성립해야 하며, LP size의 절반을 넘는 규모의 스왑이 발생했을 경우 LP가 하나의 코인만 남아 pool이 유지되지 않는 극단적인 상황이 발생할 수 있기 때문에 실사용이 어렵다.

따라서 실제로 적용해볼 수 있는 최적의 시나리오는 constant-product와 constant-sum 두 방식을 모두 취하는 것이다. 대다수의 스왑은 LP를 구성하고 있는 스테이블코인들의 비율이 비슷하게 유지되는 middle-ground 영역에서 발생한다. 따라서 해당 영역에서 발생하는 스왑에 constant-sum과 유사한 invariant를 적용하고, LP 자산의 비율을 크게 어긋나게 하는 큰 규모의 스왑에 대해서는 constant-product와 유사한 invariant를 적용하는 것이다.

Curve에서는 위와 같은 형태의 invariant 식을 얻기 위해 amplification coefficient 파라미터를 활용한 새로운 invariant를 제시하였다.

이를 설명하기 위해 먼저 constant-sum과 constant-product invariant를 일반화해보겠다. 2개의 코인으로 구성된 LP가 아닌 n개의 코인으로 LP를 구성한다고 가정했을 때 초기 LP의 balance는 다음과 같이 표현해볼 수 있다.

여기서 상수 D는 LP를 구성하는 coin들이 서로 같은 가치를 가질 때의 전체 양이고, x_i는 i번째 코인의 양을 뜻한다.

Curve whitepaper에서 얘기하는 amplified의 의미는, 어느 정도의 밸런스를 갖춘 LP에서의 곡률을 의미한다. 곡률이 클수록 곡선은 더욱 휘어지게 되고, 0으로 갈수록 직선에 가까운 형태가 된다.

Curve의 invariant를 정의하기 위해 whitepaper에서는 constant-sum은 zero slippage invariant이기 때문에 infinite leverage와 대응되는 개념이며, constant-product invariant는 zero leverage 라는 가정을 하였다. 여기서 infinite leverage의 의미는, constant-sum invariant를 적용한 LP는 constant-product invariant를 적용한 LP의 크기를 무한대로 확장한 것과 다름 없어져서 스왑 규모에 상관없이 zero-slippage를 보장한다는 뜻이다.

Curve에서는 Leverage의 값을 𝜒로 표기하였다. 𝜒로 명명하면서 𝜒가 0일 때는 constant-product가 되고, 𝜒가 infinite로 갈 때에는 constant-sum의 형태를 띠게 하는 invariant formula를 다음과 같이 정의했다.

𝜒는 dimensionless parameter이여야 하기 때문에 코인의 수에 따른 dependency를 없애주어야 한다. 따라서 dimension의 영향을 없애기 위해 위의 식처럼 기존의 invariant 식의 양변에 D^(n-1)를 곱해주었다.

여기서 𝜒가 상수인 상태의 invariant를 그대로 사용할 시 constant-product와 비슷한 문제가 발생하는데, 사용비율이 크게 벗어나는 스왑을 수행할 경우 LP 페어 자산의 균형이 깨져서 자산의 가격을 표시해주지 못한다는 문제가 있다. LP는 어떤 경우에도 pair 자산이 전부 존재하는 경우에는 가격을 표시해 주어야 한다.

Dynamic Amplification Coefficient

Curve에서는 이 문제를 해결하기 위해 𝜒를 dynamic한 값으로 바꾸었는데, LP의 비율이 동일할 때는 특정 상수 A와 같아지나, 자산의 비율이 극단적으로 깨지는 경우에는 0에 가깝게 떨어지도록 설정하였다. 여기에서 설정한 A가 바로 amplification coefficient이다.

dynamic한 𝜒를 위의 식에 대입하면 다음과 같은 invariant를 얻게 된다.

Amplification Coefficient의 직관적인 해석

위에서 수식을 통해 설명하였듯이, A가 커진다는 것은 레버리지 계수인 𝜒의 upper bound가 커지는 것을 의미하며, 이는 곧 constant-sum의 영역을 확대하는 것을 의미한다.

그림 1에서 살펴보았듯이, stable LP에서 StableSwap의 invariant는 두 페어 자산이 균형잡힌 경우에는 constant-sum과 유사하게 일정 범위 안에서 dy/dx의 값이 거의 비슷하게 유지(직선 형태)되다가 범위를 벗어날 때 급격하게 변동하는 양상을 보인다. constant-sum의 영역을 확대하는 것은 그림 1에서 직선 형태의 범위를 확장하는 것이고, 결국 조금 더 넓은 범위에 대해 안정된 가격비를 적용하는 것을 뜻한다.

따라서 stable LP의 규모에 따라서 다음과 같이 A를 설정하는 것이 적절하다고 볼 수 있다.

LP의 규모가 작을 때

• A의 값을 비교적 작게 설정
• 페어 자산이 balanced된 상황에서 일반적인 스왑에 대해 가격비가 안정화된 스왑을 제공한다.
• massive swap에 대한 경우 constant-product 쪽의 레버리지가 상대적으로 크기 때문에 일반적인 constant-product invariant를 사용하는 pool과 유사하게 동작하여 페어 자산의 imbalance를 방지한다.

LP의 규모가 클 때

• A의 값을 크게 설정
• 페어 자산이 balanced된 상황에서 마찬가지로 가격비가 안정화된 스왑을 제공한다.
• massive swap의 경우라 하더라도 LP의 규모가 크기 때문에 constant-sum의 레버리지를 상대적으로 크게 적용할 수 있어서 가격비가 안정화된 스왑을 제공하는 범위를 확장할 수 있다.

간단한 예제를 통한 StableSwap과 constant-product의 비교

간단한 스왑 시뮬레이션을 통해 StableSwap이 constant-product에 비해 얼마나 가격 안정성을 가지는지 확인해보았다. 환경 세팅은 다음과 같다.

• LP를 구성하는 coin의 수는 편의상 2종류로 고정(n=2)
• 초기 LP의 liquidity는 X coin 10000개, Y coin 10000개로 구성됨
• X coin을 LP에 투입하여 B coin을 얻는데, 투입하는 X의 수를 100개부터 시작하여 100개 단위로 증가시키며, 15000개까지 수행한다.
• A(Amplification coefficient)는 constant-product와의 비교를 수행할 때는 50, A에 따른 StableSwap의 return을 확인할 때는 1, 5, 10, 50, 100, 1000에 대해 수행

시뮬레이션으로 확인해볼 부분은 다음과 같다.

• Swap의 규모에 따른 두 invariant의 return 비교 및 slippage 차이
• Amplification coefficient의 크기에 따른 StableSwap의 return 변화

1. Swap의 규모에 따른 두 invariant의 return 비교

작은 규모의 swap부터 massive swap까지 다른 invariant에 따라 얻게 되는 교환비가 얼마나 차이나는지 확인해 보았다. swap의 규모는 LP pool의 0%부터 75%까지 0.5% 단위로 증가시키면서 시뮬레이션을 수행했다. StableSwap의 경우 amplification coefficient의 값은 50으로 설정했다.

• 상대적으로 swap의 규모가 적을 때는 StableSwap과 constant-product가 얻게 되는 Y coin의 수가 큰 차이를 보이지 않았다.
• 투입하는 X coin의 수가 증가할수록 StableSwap을 통해 얻을 수 있는 Y coin의 수가 점점 늘어났고, X 10000개를 투입할 때(초기 LP pool 생성 때 투입한 X와 같은 양)는 교환받게 되는 Y의 수량이 약 2배 가까운 차이를 보였다.
• 적은 규모의 swap일 때는 어떤 invariant를 사용하든 price slippage가 크지 않았지만, massive swap의 경우는 constant-product는 매우 큰 price slippage가 발생한 반면 StableSwap은 거의 일정한 비율의 교환비를 보여주었다.

2. Amplification coefficient의 크기에 따른 StableSwap의 return 변화

StableSwap에서는 위에서 설명하였듯이 Amplification coefficient의 값 조절을 통해 안정화된 교환비를 제공할 수 있는 범위를 결정하게 된다. A의 값에 따라 small amount of swap 부터 massive swap에 이르기까지 교환비의 차이가 어느 정도 발생하는지 시뮬레이션 해보았다.

• swap의 규모가 작으면 전체적으로 좋은 교환비를 제공했다.
• swap의 규모가 커질수록 A 값이 큰 StableSwap이 교환비 측면에서 훨씬 높은 안정성을 보였다.
• A=1000에서 초기 LP pool 공급량(X 10000개, Y 10000개)을 넘어서는 swap이 발생할 경우 최대한 교환비를 지키기 위해 LP에 존재하던 모든 Y coin을 return으로 주게 되는데, 한쪽 자산만 남게 되어 LP pool이 깨질 수 있다.

시뮬레이션 관련 코드는 아래에서 확인할 수 있다.

마치며

모든 것에는 trade-off가 있다. constant-product invariant를 가격 결정 알고리즘으로 사용한 AMM은 탈중앙화된 블록체인에서 두 페어 자산의 스왑을 가능하게 했지만, LP의 규모가 작거나 pool에 비해 규모가 큰 swap이 발생할 경우 자산의 교환비를 지키지 못해 큰 price slippage가 발생한다는 문제가 있었다. 이는 스테이블코인 간 스왑에 치명적인 단점으로 작용했다. Curve의 StableSwap은 여기에 constant-sum과 constant-product의 하이브리드 형태인 새로운 방식의 invariant를 제시하였고, 특정 범위 안에서 거의 일정한 교환비로 swap을 제공할 수 있게 되었다. 하지만 이 역시 큰 규모의 swap에서는 교환비를 지키기 위해 LP 자산의 균형을 깰 수 있다는 단점이 존재한다. 따라서 가장 이상적인 스테이블코인 페어 LP의 운용방법은 페어 풀의 규모를 크게 설정하고 StableSwap을 사용하는 것이지만, 여건이 되지 않을 경우 각 invariant의 장단을 파악하여 적절히 취사선택하는 것이 필요하다.

Curve finance의 StableSwap was originally published in BerryFi on Medium, where people are continuing the conversation by highlighting and responding to this story.

Author: 표정우

Audited By: 이태헌, 이동헌

[OlympusDAO 시리즈]

1. Introduction
2. Bonding 컨트랙트 코드 리뷰
3. Treasury 및 Staking 컨트랙트 코드 리뷰
4. 주목할 만한 기능들

Treasury 동작 메커니즘

Treasury의 역할

Treasury는 OlympusDAO에서 OHM의 가치를 backing하기 위한 여러 reserve token과 LP들이 보관되어 있는 컨트랙트이다. Bond의 구매를 통해 reserve token LP를 지불하면 지불된 token들은 해당 컨트랙트에 저장되며, 이렇게 모인 token의 가치는 발행되는 OHM의 가격을 지지하는(backing) reserved asset의 역할을 한다.

reserve token이 예치될 때마다 그 가치들은 totalReserves 라는 상태변수에 합산된다. 이를 현재 유통 중인 OHM의 수로 나누게 되면 OHM의 이론적인 backing price(가격하한선)을 구할 수 있다. 또한 excessReserves()를 통하여 OHM의 공급대비 얼마나 많은 reserved asset이 쌓였는지를 파악할 수 있어서 treasury에 쌓인 reserved asset에 비해 유통되고 있는 OHM의 발행량이 많을 때, 이에 비해 과도한 OHM의 발행을 요청하는 경우 excessReserves() 에 의해 OHM의 추가 발행을 막음으로써 OHM의 가격 하락을 막는다.

Treasury 컨트랙트에서 사용되는 자료구조 및 상태 변수

Treasury.sol에서 정의된 자료구조는 다음과 같다.

enum STATUS는 reserve의 예치자, 소비자, reserve token 등의 역할을 정의해 놓은 type이다. struct Queue는 매니징할 토큰에 대한 정보를 저장하는 자료구조로 treasury에 존재하는 각종 토큰에 접근할 수 있는 권한을 관리하는 부분에서 사용하게 된다.

Treasury에서 사용되는 주요 상태 변수는 다음과 같다.

먼저 permissionQueue는 Queue의 array로, permissions 변수에 주소의 권한을 얻기 위해 queueTimelock() 함수에서 채워지는 상태 변수이다. 이후, execute()에 의해 permissionQueue에 채워진 Queue가 실행되며 permissions 등의 권한을 저장하는 상태변수에 특정 주소의 권한이 주어진다.

registry는 reserve token과 liquidity token을 보유하고 있는 account list이며, 추후에 auditReserves()를 통해 deposit이나 withdraw 등의 함수에 의해 계산된 totalReserves의 값이 맞는지 확인하는 용도로 사용된다.

permissions는 STATUS의 특정 타입에 대해 특정 주소의 접근권한 여부가 저장되어 있는 상태 변수이다. Treasury.sol에서 정의된 대부분의 함수들이 함수 실행 전 해당 변수를 확인하여 sender의 권한을 확인한다.

bondCalculator는 liquidity token의 contract 주소와 이를 계산하는 calculator의 주소의 매핑을 저장하는 변수이다. calculator의 경우 나중에 자세히 설명하겠지만, Uniswap과 같은 DEX에서 해당 토큰의 시장 가격을 불러오거나 LP token의 수를 파악할 때 사용하게 된다.

Treasury 컨트랙트의 함수 기능 설명

기본적으로 treasury contract의 함수는 permissions[STATUS]에 주소가 list 되어있는지에 따라 실행할 수 있는 함수가 다르니 이를 미리 파악하는 것이 좋다.

1) deposit

deposit 함수는 bond에서도 똑같이 정의되어 있는데, bond의 deposit은 실제 사용자가 채권을 구매할 때 사용하는 데 반해 treasury의 deposit은 reserve allocator와 상호작용하게 된다.(f6cd363 커밋 기준으로 allocator 관련 코드가 구현되어 있지 않지만, 다이어그램에 allocator의 역할이 명시되어 있어서 본 글에서는 allocator에 대한 언급만 하고 contract 관련 설명은 생략한다.) reserve allocator는 treasury fund를 Aave, Curve와 같은 외부의 디파이 전략을 사용하기 위해 배포된 컨트랙트를 말한다. treasury의 deposit은 treasury로부터 fund를 인출한 후, 이를 다시 돌려놓을 때 사용하는 컨트랙트이다. fund를 인출할 때는 후에 설명할 manage() 를 이용한다.

• _amount만큼의 _token을 treasury에 예치한다.
• 예치한 토큰의 총 가치는 value 이며, value-_profit 에 해당하는 OHM을 sender에게 발행한다. 처음 Treasury에 token을 채워넣을 때에는 OHM이 발행되지 않게 하기 위하여 _profit에 tokenValue와 동일한 값을 전달한다. 그 이후에는 0을 전달하여 value에 해당하는 OHM을 발행하게 된다.
• reserve depositor 혹은 liquidity depositor permission 소유자만이 실행할 수 있다.

토큰의 market price를 알기 위해서는 해당 토큰이 상장된 거래소에서 가격 정보를 불러오거나, 토큰이 거래되고 있는 DEX(ex. Uniswap, sushiswap, Pancakeswap 등)에서 해당 토큰-stable coin의 페어 풀로부터 알아내는 두 가지 방법이 있다. 그러나 첫 번째 방법 같은 경우는 외부의 잘못된 정보를 블록체인 내부로 가져오면서 발생하는 블록체인 오라클 문제가 발생할 수 있고, 실제로 상장이 안 되어 있을 경우 market price를 매길 방법이 없다. 따라서 OlympusDAO에서는 후자의 방법을 사용하며, tokenValue()에 의해 market price를 불러오게 된다.

tokenValue()가 market price를 불러오는 방법에 대해 자세히 설명하자면, reserve token의 market price는 UniswapV2로부터 LP 풀의 정보를 불러와 LP 풀에 예치된 토큰의 비율을 파악하는 방식으로 이루어진다.

Token-DAI LP pair를 이루고 있는 Token의 수를 x, DAI의 수를 y라고 한다면, 보유하고 있는 토큰의 양(amount)의 가치(value)는 다음과 같이 산정된다.

따라서, Bond를 수행할 때 위 메커니즘에 의해 LP pair를 구성하고 있는 reserve token의 가치를 파악할 수 있고 reserve asset에 즉각 반영된다.

2) manage & withdraw

두 함수는 treasury에 예치되어 있는 token을 인출하는 함수이다.

withdraw

• reserve spender permission 소유자가 실행 가능하다.
• 보유하고 있는 OHM을 소각한 후, 동일한 가치에 해당하는 token을 _amount만큼 빼 온다.

manage

• liquidity manager나 reserve manage에 대한 permission이 있어야 실행 가능하다.
• OHM을 보유할 필요 없이, 원하는 만큼의 token을 인출한다. 단, 그 value가 treasury의 reserve를 초과하는 경우에는 revert된다.

3) mint

• recipient에게 _amount 만큼의 OHM을 발행해주는 함수로, reward manager permission 소유자만이 이를 실행할 수 있다
• excessReserves()를 통해 OHM의 유통량이 과도하거나 treasury에 저장된 reserve에 비해 많은 OHM의 발행을 요구하는 경우 mint를 revert함으로써 채권을 판매할 때나 staking의 이자를 배분할 때 OHM이 너무 많이 풀리지 않게 OHM의 공급을 조절한다.
• 해당 함수는 bonding contract에서 사용자들이 reserve token이 포함된 LP를 지불하여 할인된 OHM을 구매하는 채권 구매 프로세스에서 호출된다.
• 이후에 Staking 쪽에서 distributor들이 sOHM에 대한 이자를 분배할 때에도 활용하는 함수이다

Staking의 동작 메커니즘

Staking의 역할

스테이킹은 OHM의 가격을 지지하게 해주는 중요한 기능이다. Bond를 통해 OHM을 market price보다 작은 가격으로(높은 할인율로) 구매하게 된다면, OHM의 가격은 지속적으로 떨어질 것이고 이를 예방하기 위한 방법은 OHM staking을 통해 고이율의 이자를 지급함으로써 staker들에게 OHM을 보유할 유인을 제공하는 것이다.

OHM과 sOHM, gOHM

Staking contract 코드를 설명하기 전에 OHM과 sOHM, gOHM의 차이를 알아야 한다. 사용자가 OHM을 소유하고 있으면, 다른 주소에 전송하는 등 일반 토큰과 같이 사용할 수 있다. 하지만 이자를 수령하기 위해 가지고 있는 OHM을 Staking contract에 맡기게 되면 sOHM의 형태로 고정되어 이를 자유롭게 사용하지 못한다. 물론 Unstake를 수행하면 락업기간 없이 다시 OHM을 돌려받을 수는 있지만, 이자를 수령하지 못한다.

gOHM은 일종의 wrapped sOHM으로, OlympusDAO V2에서 소개되는 개념이다. gOHM은 OHM의 스테이킹 이자를 받으면서 자유롭게 거래가 가능하다. 다만 리베이스 시간(이자를 지급하는 term)마다 개수가 증가하는 것은 아니고, gOHM의 가격이 증가하는 형태로 이자를 지급하게 된다. gOHM의 가격은 다음과 같은 식으로 표현된다.

$gOHM_{price} = OHM_{price} * CurrentIndex$

$CurrentIndex$는 epoch이 지날 때 마다 incremental하게 증가하는 값으로, 시간이 지날수록 OHM의 market price가 감소하지 않는다는 전제 하에 지속적으로 증가하는 구조를 가지고 있다. 참고로 OlympusDAO의 공식 문서에서는 gOHM을 “sOHM이 들어있는 가방” 이라는 표현을 들어가며 설명하니 참고해도 좋다.

아래의 Staking contract을 설명하는 부분에서는 sOHM과 gOHM을 다루는 함수가 있을 때 _rebasing 이라는 argument를 전달하는데, 스테이킹 이용자가 sOHM 혹은 gOHM을 받기를 원하는지에 따라 _rebasing 값이 True 혹은 False로 달라지게 된다.

Staking 컨트랙트에서 사용되는 자료구조 및 상태 변수

OlympusDAO에서는 epoch 단위로 스테이킹에 대한 이자를 지급하게 된다. struct Epoch은 말 그대로 스테이킹 epoch에 대한 정보를 담을 수 있는 구조이다. Epoch 안의 distribute는 해당 epoch에서 staker들에게 나눠줄 이자의 양을 의미한다. 현재 Epoch의 정보는 epoch 상태 변수 안에 담긴다.

struct Claim 은 사용자가 OHM을 staking 할 때 각 사용자들의 staking 정보를 담는 구조체이다. Staking contract에서는 해당 구조를 address를 key로 하는 매핑 변수인 warmupInfo에 담는다.

Staking 컨트랙트의 함수 및 기능 설명

1) Stake

• sender가 스테이킹하려는 OHM을 Staking contract에 전송한다.
• _claim이 False이면 warmupPeriod에 관계없이 스테이킹한 OHM의 담보에 해당하는 sOHM이나 gOHM을 받게 된다.
• _claim이 True일 경우 lock-up이 있어서 expiry가 지난 경우에야 sOHM이나 gOHM을 받게 된다.

2) Claim, Forfeit & Unstake

Claim

• OHM을 스테이킹함으로써 sOHM 혹은 gOHM에 대한 이자가 쌓이는데, 스테이킹한 원금과 이자를 수령하는 함수이다.
• warmupInfo[_to].gons에 원금+이자가 기록되어 있는데, 해당 sOHM(혹은 gOHM)을 _to 주소에게 전송한 후 warmupInfo[_to]를 삭제한다.

Forfeit

• 스테이킹을 종료하고 맡긴 OHM을 수령하는 함수이다.
• claim() 과의 차이점은 claim()은 sOHM 혹은 gOHM의 형태로 수령하고, forfeit()은 OHM의 형태로 수령한다.

Unstake

• 보유한 sOHM 혹은 gOHM을 반환 혹은 소각하고 이에 상응하는 OHM을 수령하는 함수이다.

3) Rebase

Rebase는 현재 epoch이 종료되었을 때(block.timestamp가 epoch.end를 초과하였을 때) staker들에게 제공할 sOHM의 이자율을 포함한 여러 값들을 갱신하는 함수이다.

• epoch.distribute는 이자율에 따라 늘어난 sOHM의 양으로, 현재 epoch에서 이자로써 staker들에게 제공될 sOHM을 뜻한다.
• epoch.distribute의 값은 sOHM.rebase()의 profit_ 인자에 해당하는 값으로 전달된다.

• sOHM.rebase()에서는 rebaseAmount를 구하고 이를 totalSupply에 합하게 되는데, 그 값은 인자로 전달받은 epoch.distribute에 totalSupply/circulatingSupply를 곱한 값이다.
• _gonsPerFragment는 전체 공급량 기준으로 sOHM 1개의 비율에 해당하며, 결국 전달받은 epoch.distribute의 값에 비례해서 sOHM이 발행량이 증가하게 되고 그만큼 개개인의 이자수익이 증가하게 된다.
• 다음 epoch의 이자율에 해당하는 양만큼 treasury가 staking contract에 mint를 수행하고, bounty가 있을 경우 역시 추가로 treasury가 mint를 수행한다.
• 다음 epoch의 distribute는 (staking된 OHM의 수 — sOHM의 유통공급량 — bounty) 에 해당하는 양만큼 발행을 하게 되며, 이 값이 음수일 경우 distribute의 값은 0이 된다.

4) 기타 함수

_send

• sOHM 혹은 gOHM을 staker에게 보내는 internal function이다.
• _rebasing 값이 True일 경우 sOHM, False일 경우 gOHM의 양을 return한다.

wrap & unwrap

• wrap은 sOHM을 gOHM으로 변환하는 함수이며, unwrap은 그 반대이다.

마치며

이번 글에서는 올림푸스다오의 Treasury와 Staking의 메커니즘을 코드 레벨로 파악해 보았다. 이로써 올림푸스다오의 주요 기능을 어느 정도 파악하였으니, 마지막 글에서는 올림포스다오의 메커니즘에 대한 전반적인 요약 및 Q&A를 다루면서 올림푸스다오 시리즈를 마무리하도록 하겠다.

[OlympusDAO를 분석해보자] — 3. Treasury 및 Staking 컨트랙트 코드 리뷰 was originally published in BerryFi on Medium, where people are continuing the conversation by highlighting and responding to this story.

서울대학교 블록체인 학회 ‘디사이퍼(Decipher)’에서 블록체인 기술에 관한 글을 연재합니다. 이번 주제는 “Zero-Knowledge Proof”이며, chapter 1. Introduction to Zero-Knowledge Proof & zk-SNARKs, chapter 2. Deep Dive into zk-SNARKs 로 나누어 설명합니다.

본 글의 작성을 위해 https://blockgeeks.com/guides/what-is-zksnarks/ 의 전체적인 흐름을 참고했으며, 설명의 용이성 및 완결성을 위해 원 글의 설명을 기반으로 타 참고자료 및 직접 제작한 자료를 추가하였습니다.

최근 블록체인 업계는 엄청난 자본의 유입으로 산업이 빠른 속도로 발전하고 있다. 산업의 발전 속도에 따라 기술의 발전 또한 빨라졌지만, 여전히 블록체인은 확장성이나 보안성 등 여러 부분에서 보완해야 할 점이 많은 기술이다. 그 중 한 가지 문제가 프라이버시 문제이다. 퍼블릭 블록체인에서 개인 간의 트랜잭션이 발생하면, 트랜잭션의 상세 내역이 모두에게 공개되기 때문에 이로 인한 피해를 입을 수 있다. 또 다른 문제는, 계속해서 증가하는 블록체인의 용량이다. 이러한 두 가지 문제를 해결할 수 있는 방식으로 zk-SNARKs라는 개념이 대두되었다. zk-SNARKs가 도입되면 거래의 익명성을 보장하고, 블록체인 데이터를 짧은 해시값으로 압축시켜 저장 용량을 줄여줄 수 있다. 먼저 zk-SNARKs의 근간이 되는 zero-knowledge proof가 무엇인지에 대해 알아보도록 하자.

zero-knowledge proof(이하 ZKP)는 prover가 자신이 알고 있는 지식을 공개하지 않으면서, 그 지식을 알고 있다는 사실을 verifier에게 증명하는 proof system으로, 1980년대 MIT의 Shafi Goldwasser, Silvio Micali and Charles Rackoff가 처음 제시했다. 여기서 prover는 knowledge을 알고 있음을 증명하는 주체이고, verifier는 prover가 해당 knowledge을 알고 있다는 사실을 확인 및 검증해주는 주체이다. ZKP의 이론적인 기반은 interactive proof system이다. Interactive proof system이란, prover와 verifier 상호 간 메시지를 교환하는 computation을 모델링한 abstract machine(이론적인 컴퓨팅 모델)을 뜻한다.

Interactive proof system에서 prover는 전능하고 무한정의 계산 자원을 가지고 있지만 신뢰할 수 없는 존재인 반면, verifier는 한정된 계산 자원을 가지고 있지만 신뢰할 수 있는 존재임을 전제한다. 그렇기 때문에 지금까지 interactive proof system과 관련된 대부분의 공격 시나리오는 prover가 악역을 맡고, 이들이 verifier를 속이려고 하는 상황을 가정하였다. 하지만 ZKP를 제시한 위 3명의 연구자들은 interactive proof system에서 추가적으로 verifier가 악의적인 목적을 품는 시나리오에 대하여 생각해 보았다. 예를 들어, prover가 자신의 주민등록번호를 알고 있고, 자신이 알고 있다는 사실을 증명하기 위해 관련 정보를 verifier에게 보낸 상황을 가정하자. 이 때, verifier는 전달받은 prover의 정보를 타인에게 판매하여 부당한 이익을 챙길 수 있다. 이와 같은 경우는 기존의 interactive proof system에서 다루고 있지 않던 문제였다. 따라서 이를 예방하기 위해 그들은 기존의 interactive proof system에 다음과 같은 2가지 질문을 던졌다.

1. 누구나 verifier가 knowledge를 누설하지 않았다는 걸 확인할 수 있는가
2. verifier가 검증 과정 동안 알고 있어야 하는 knowledge의 비중은 어느 정도인가

위 의문점들을 해결하기 위해서 prover가 제공한 proof를 통해 악의적인 verifier가 검증을 수행할 수는 있지만, prover의 knowledge 자체에 대해서는 유추할 수 없는 proof system이 필요했다. 깊은 고민 끝에 그들이 내놓은 해결책이 바로 ZKP 이다.

ZKP의 property

Zero-knowledge proof는 항상 다음과 같은 조건을 모두 만족하여야 한다.

• Completeness: 어떤 조건이 참이라면, honest verifier는 honest prover에 의해 이 사실을 납득할 수 있다.
• Soundness: 어떤 조건이 거짓이라면, dishonest prover는 거짓말을 통해 verifier에게 조건이 참임을 절대 납득시킬 수 없다.
• Zero-knowledge: 어떤 조건이 참일 때, verifier는 이 조건이 참이라는 사실 이외의 정보를 아무것도 알 수 없다.

Completeness와 Soundness는 일반적인 interactive proof system이 가지는 properties 이다. ZKP는 이를 만족하면서 추가적으로 세 번째 조건인 Zero-knowledge property까지 만족해야 하고, 결국 세 번째 조건이 ZKP의 주요한 property이다.

ZKP 가 적용된 사례를 다음 세 가지 예제를 통해 알아보자.

Examples of ZKP

Case 1: Alibaba’s Cave

아마 인터넷에 ZKP를 검색하면 나오는 대표적인 문제 중 하나가 Alibaba’s cave일 것이다. 그림과 같이 고리 형태의 동굴 가운데에 문이 있고, 그 문에는 도어락이 설치되어 있다. verifier는 prover에게 동굴에 설치된 도어락의 비밀번호가 무엇인지 직접 물어보지 않고 prover가 비밀번호를 알고 있다는 명제가 참인지를 확인하고 싶다. 이 조건문이 참인지를 확인하기 위해, 다음과 같은 과정을 따른다.

1. prover가 먼저 동굴에 들어간 다음, 도어락 근처로 이동한 후 verifier를 동굴 안으로 부른다.
2. verifier는 A와 B의 갈림길에 서서, prover에게 특정 길(A 또는 B)로 나오라고 지시한다.
3. prover는 verifier가 지시한 길로 나온다.
4. 1.~3. 과정을 반복한다.

1.~3. 과정만을 보았을 때는, prover가 정말 도어락의 비밀번호를 알고 있어서 verifier가 지시한 길로 나왔는지 확신할 수 없다. 우연에 의해 처음부터 prover가 A를 선택했고, 문을 열지 못했으나 verifier가 A로 나오라고 지시하는 경우가 충분히 있을 수 있기 때문이다. 따라서 우연의 가능성을 낮추기 위해, 위 과정을 일정 횟수 이상 반복한다. 여러 case를 수행하였을 때에도 매번 prover가 verifier의 지시대로 행동한다면, prover가 도어락의 비밀번호를 알고 있다는 사실을 verifier에게 납득시킬 수 있다.

이 예제에 ZKP의 property을 매핑시켜 보면 다음과 같다고 말할 수 있다.

• Completeness: 어떤 조건이 참이라면, honest verifier는 honest prover에 의해 이 사실을 납득할 수 있다. => 여러 번의 경우에도 prover가 verifier의 지시를 지속적으로 따른다면, verifier는 prover가 도어락의 키를 안다고 납득할 수 있다.
• Soundness: prover가 정직하지 못하다면, prover는 거짓말을 통해 verifier에게 조건의 타당함을 납득시킬 수 없다. => prover가 사실은 도어락의 키를 모르지만 안다고 거짓말을 하였을 경우, verifier에게 언젠가 한 번은 지시대로 수행하지 못하는 경우가 생길 것이기 때문에 자신이 도어락의 키를 안다는 것을 증명할 수 없다.
• Zero-Knowledge: 어떤 조건이 참일 때, verifier는 이 조건이 정확히 무엇인지 알지 못하여야 한다. => 여러 번의 수행을 통해서 verifier는 prover가 도어락의 키를 알고 있다는 사실을 납득하였지만, 도어락의 키가 무엇인지에 대해서는 알지 못한다.

Case 2: Finding Waldo

이것은 “Spot the guy”라는 게임과 비슷하다. 위와 같이 여러 종류의 색상이 혼합된 다소 산만한 그림에서 Waldo라는 아래 그림과 같은 특정 인물을 찾아내는 것이다.

위 문제를 푸는 데에는 크게 2가지 솔루션이 존재한다.

• First solution

Waldo’s problem에서 prover가 Waldo를 찾았다는 것을 verifier에게 증명하는 첫번째 방법은 다음과 같다. 먼저, prover와 verifier가 같은 사진을 복사하여 한 장씩 나눠가진다. prover는 사진 속에서 Waldo가 있는 부분을 찾아서 자른 다음 나머지 부분을 버린다. 나머지 부분을 버렸기 때문에 prover가 자른 Waldo 조각이 사진에서 어디에 위치해 있는지는 verifier에게 밝혀지지 않는다. 그리고 나서 prover는 Waldo가 포함된 조각을 verifier에게 보여준다. prover와 verifier는 같은 사진을 나누어 가졌기 때문에, verifier는 prover가 증거로써 제시한 Waldo 조각이 같은 사진로부터 나왔음을 납득할 수 있고, prover는 Waldo가 어디에 위치해 있는지 밝히지 않으면서(zero-knowledge) Waldo가 위치한 곳을 찾았음을 verifier에게 증명할 수 있게 된다.

하지만 본 solution은 “soundness”의 기준을 충족시키지 못한다. 왜냐하면 prover가 verifier를 속이는 다양한 방법이 존재하기 때문이다. 실제로 사진에 포함되어 있지 않더라도, Waldo의 모습을 알고 있으면, prover와 verifier가 따로 떨어져 있을 때 Waldo의 모습을 기존의 사진과 같은 재질과 크기의 용지에 프린트한 후 내가 Waldo가 위치한 곳을 아는 것처럼 눈속임할 수 있게 된다. 이러한 문제는 어떻게 해결할 수 있을까?

해결할 수 있는 방법 중 하나는 prover에게 사진을 주기 전에, verifier가 사진 뒷면에 구별할 수 있는 패턴을 그려 넣는 것이다. 그리고 verifier가 prover를 고립된 방에서 문제를 해결하게 둠으로써 prover가 cheating할 수 있는 기회를 원천 차단한다. 후에 prover가 Waldo가 포함된 조각을 verifier에게 제출하고, 위 과정을 여러 번 반복한다. 나중에 prover가 제출한 Waldo의 조각들의 배경들은 조금씩 다를 테지만, 뒷면에 나와 있는 특정 패턴이 일정하다면 verifier는 비로소 Waldo가 어디에 위치해 있는 지 모르더라도 prover가 이를 알고 있다는 것을 납득할 수 있게 된다.

• Second solution

Second solution은 매우 간단하다. 주어진 photo의 2배 이상 크기의 cardboard를 준비한 뒤, 직사각형의 구멍을 뚫어 놓는다. 그 구멍을 통해 prover는 사진에 있는 Waldo의 모습을 verifier에게 직접 보여준다. verifier는 cardboard의 뒷면을 볼 수 없기 때문에 실제로 자신이 보고 있는 Waldo가 사진에 어디쯤 위치해 있는지 알 수는 없지만(Zero-Knowledge), prover가 알고 있다는 것을 납득할 수 있게 된다.

Case 3: Mini Sudoku

# 이 case는 Ethereum Foundation의 Christian Reitwiessner가 devcon3에서 발표한 자료를 참고하였다.

다들 Sudoku 게임을 최소한 한 번씩 해봤거나, 적어도 게임에 대해 들어본 경험이 있을 것이다. Sudoku란 주어진 9*9 정사각형 판에 있는 각각의 가로, 세로줄에 1부터 9까지의 숫자를 한 번씩만 사용하여 판을 모두 채우는 게임이다. 이 9*9 정사각형 판은 다시 9개의 작은 3*3 정사각형 판으로 쪼개져 있는데, 해당 정사각형 판에도 1에서 9까지의 숫자가 한 번씩만 들어가야 한다.

ZKP를 실제 Sudoku 문제에 대입해 설명할 수도 있지만, 이를 통해 설명하기에는 너무 경우의 수가 많아지기 때문에 9*9 판을 4*4로 축소한 버전인 Mini Sudoku 게임을 통해 설명하도록 하겠다.

Mini Sudoku 문제가 주어졌을 때, prover와 verifier가 해결하고자 하는 일은 다음과 같다.

• prover: Mini-Sudoku의 해답을 공개하지 않고, 해당 문제가 풀릴 수 있다는 것을 증명하려 함
• verifier: prover가 Mini-Sudoku의 해답을 알고 있다는 것을 납득하려 함

이를 증명하는 과정은 다음과 같은 세 단계로 이루어진다.

1. Shuffling solution
2. shuffled solution과 mapping table을 가리는 과정
3. verifier가 선택한 sub solution을 공개하는 과정
4. shuffling solution

prover는 random one-to-one mapping을 통해, 가지고 있는 solution을 변형하는 과정을 거친다.

위 그림에서, 좌측에 위치한 판이 prover가 실제 가지고 있는 solution이다. prover는 이 solution을 verifier에게 바로 공개할 수는 없으니, 기존의 숫자를 다른 숫자로 겹치지 않게 shuffling시킨다. 우측의 판은 mapping table에 의해 한번 shuffle된 shuffled solution이다.

2. shuffled solution과 mapping table을 가리는 과정

prover는 shuffled solution과 mapping table을 verifier에게 공개하지 않고, 각각의 값을 숨긴 뒤에 공개를 하게 된다.

3. verifier가 선택한 sub solution을 공개하는 과정

Sudoku에는 여러 sub solution들이 존재한다. 만일 prover가 solution을 알고 있다면, verifier가 다음과 같은 정보의 공개를 요구했을 때 이를 모두 만족해야 비로소 sudoku 문제의 해법을 안다고 할 수 있다.

• 특정 row를 공개했을 때, 해당 row에 포함된 숫자가 모두 달라야 함
• 특정 column을 공개했을 때, 해당 column에 포함된 숫자가 모두 달라야 함
• 특정 sub-square를 공개했을 때, 해당 sub-square에 포함된 숫자가 모두 달라야 함
• 임의의 cell들을 공개했을 때, 공개된 cell들이 기존 sudoku의 constraint를 해치지 않아야 함

위 조건들 중에서 verifier가 한 가지를 선택하여 정보공개를 요구할 수 있다. 예를 들어서, verifier가 “column 2를 공개하라”는 요청을 했다고 가정하자. prover는 요구 조건에 맞추어 masking한 column 2을 공개하게 된다.

공개된 solution은 sudoku의 constraint(특정 column에는 1부터 4까지의 숫자가 한번씩만 들어간다)를 해치지 않기 때문에, 위 사실은 verifier로 하여금 prover가 정말 solution을 알고 있다고 납득할 수 있게 되는 근거가 된다. 하지만 위 사실만을 가지고 prover가 solution을 알고 있다고 하기에는 무리가 있다. 왜냐하면 sub-solution을 만족하더라도 공개되지 않은 판에 적힌 숫자들은 sudoku의 solution이 아닐 수 있기 때문이다. 따라서 1.부터 3.까지의 과정을 여러 번 반복함으로써 판단의 정확성을 높이게 된다.

위 과정을 반복할 때마다, 1.의 shuffling solution 수행 전에 매번 mapping table을 새로 구성해야 한다. 만일 mapping table을 새로 만들지 않고 같은 mapping table을 계속 사용할 경우, prover가 sub-problem을 공개할 때의 단서를 모아서 실제로 prover가 어떤 solution을 가지고 있는 지 유추할 가능성이 생기게 된다. 이는 zero-knowledge의 특성에 반하기 때문에 prover의 solution을 verifier가 알 수 없도록 새로운 mapping table을 통해 shuffling을 해 준다.

결론적으로, 1. ~ 3.의 반복을 통해 prover는 자신의 solution을 공개하지 않으면서, solution을 알고 있다는 것을 증명할 수 있게 된다.

지금까지 위 세 가지 예제를 살펴보았는데, 이 예제들에서 공통적으로 발견되는 부분이 있다. 바로 prover와 verifier가 항상 on-line 상태여야 한다는 점이다. 이러한 constraint는 전체적으로 보았을 때 매우 비효율적인 구조로, 어느 정도의 개선이 필요했다. 1986년, Fiat과 Shamir가 결국 non-interactive ZKP를 제시하였고 이는 prover와 verifier의 on-line 여부에 관계없이 증명을 할 수 있도록 고안되었다. 다음에 소개할 Schnorr Identification Protocol도 non-interactive ZKP의 방식 중 하나이다.

From interactive to non-interactive: Schnorr Identification Protocol

Non-interactive 의 핵심은 결국 prover와 verifier의 메시지 교환이 최소화 되어야 한다는 것을 의미한다. 즉, prover가 특정 메시지를 verifier에게 보내고 난 다음 차후의 작업을 처리할 때 verifier로부터 추가로 전달받는 메시지가 필요하다면 이는 non-interactive한 방식이 아니다. prover가 증명에 필요한 메시지를 보내고 난 후 연결이 끊어진다고 하더라도 결국에는 그 메시지가 verifying되어야 하는 것이 non-interactive proof의 핵심이다.

암호학에서, Schnorr Protocol은 prover가 자신의 private key를 공개하지 않고 이를 가지고 있다는 것을 증명할 수 있는 방법이다. 키 교환과 관련된 프로토콜이기 때문에 지금까지 소개한 예제 중에 실제 블록체인에 적용될 수 있는 non-interactive ZKP와 가장 가까운 예제이다.

먼저, prover만 알고 있는 변수와, prover 및 verifier가 같이 공유하는 변수들은 다음과 같다. 각 변수의 값을 선택 혹은 도출하는 방식은 아래의 그림을 참고하길 바란다.

prover는 s의 값을 verifier에게 공개하지 않고, 자신이 s를 알고 있다는 것을 납득시키려 한다.

먼저, prover는 random value인 r (0<r<q) 을 하나 선택하여 그에 따른 X 값을 계산한다. 그리고 나서 prover는 보내고자 하는 메시지 M과 X 값을 concatenate 시킨 후 이를 hash function에 통과시켜 새로운 서명 e를 만든다. e를 만든 이후에, prover는 이로부터 또 다른 서명 y 값을 도출해낼 수 있다. prover는 M과 도출해낸 서명 e, y 를 verifier에게 보낸다. 참고로, 이 방식은 non-interactive하기 때문에 prover는 해당 메시지를 보내고 난 후 off-line 상태가 되어도 증명에는 지장이 없다.

verifier가 prover로부터 받은 정보를 통해 수행하여야 할 것은, M,e,y를 통해 reproduce한 X’와 prover가 가지고 있는 X가 일치하는지를 확인하는 것이다. 그런데 정확히 말해서 X는 prover만 알고 있는 정보이기 때문에 reproduce한 X’와 X가 같은지를 직접적으로 비교할 수는 없다. 이에 verifer는 다음과 같은 과정을 통해 X’ 를 도출해낸다.

위와 같은 과정에 따라 X=X’ 임을 확인할 수 있다. 하지만 여기서 증명을 끝낸다면, verifier가 X’ 값을 도출하였어도 실제로 X와 같은지를 확인할 방법이 없다. 왜냐하면 verifier는 X값을 prover로부터 전달받지 못했기 때문이다. 그래서 verifier는 도출한 X’를 이용하여 e’ 값을 계산한다.

만일 실제로 X=X’ 라면, e = e’가 되어 verifier는 X=X’임을 납득할 수 있고, 결국 verifier는 private key s 값이 무엇인지는 모르지만, prover가 s를 알고 있다는 사실을 수학적으로 납득할 수 있게 된다.

위 예제가 ZKP의 property를 만족하는지 확인해 보겠다.

• Completeness: 어떤 조건이 참이라면, honest verifier는 honest prover에 의해 이 사실을 납득할 수 있다. => X = X’ 가 참이라는 사실을 honest prover에 의해 납득할 수 있다.
• Soundness: prover가 정직하지 못하다면, prover는 거짓말을 통해 verifier에게 조건의 타당함을 납득시킬 수 없다. => prover가 private key를 몰랐을 경우, prover는 X = X’ 임을 납득시킬 수 없었을 것이다..
• Zero-Knowledge: 어떤 조건이 참일 때, verifier는 이 조건이 정확히 무엇인지 알지 못하여야 한다. => verifier는 결국 prover의 private key를 알지 못한다.

Add one more property — Succinctness: zk-SNARKs

zk-SNARKs는 zero-knowledge Succinct Non-interactive Argument of Knowledges의 줄임말로, 기존의 non-interactive ZKP에서 succinctness(간결함)가 추가된 개념이다.

기존의 non-interactive ZKP는 prover가 항상 on-line 상태일 필요가 없다는 장점이 있지만, 증명을 완료하는데 상당한 시간이 걸릴 수 있다는 단점이 있다. 간단한 예로, 위에서 언급한 Schnorr Identification Protocol에서도, verifier가 X’를 계산하기 위해서는 a^r mod p 라는 연산을 수행해야 한다. 언뜻 보기에는 쉬워 보이지만, 사실 이 연산은 a, r, p의 값이 커짐에 따라 상당한 시간이 소요되는 연산이다. 특히 암호학에서 사용되는 숫자의 크기는 매우 크기 때문에, 간단해 보이는 연산도 엄청난 횟수의 instruction을 수행하고 난 후에야 결과를 도출할 수 있다.

zk-SNARKs 에서 중요한 property는 바로 succinctness 이다. 글의 도입부에서 언급했듯이 interactive proof system은 verifier가 한정된 계산 자원을 가지고 있음을 전제로 한다. prover가 특정 knowledge를 알고 있다는 증거로 제출한 proof가 엄청난 size의 데이터라면, 이의 증명은 굉장히 비효율적일 것이다. 따라서 zk-SNARKs에서는 non-interactive ZKP의 proof size를 줄이고 빠른 시간 내에 verify를 수행할 수 있도록 하여 non-interactive ZKP의 실용성을 극대화하였다.

그렇다면 zk-SNARKs 의 동작 방식에 대한 설명을 통해 succinctness가 어떻게 적용되는지 확인해보도록 하자. 설명의 간결함을 위해 key generator G의 자세한 생성 과정, 알고리즘 P와 V의 세부 구현 등 자세한 동작 방식은 이후의 글에서 다룰 예정이며, 수학적으로 디테일한 부분은 Eli Ben-Sasson의 paper를 참고하기 바란다.

zk-SNARKs는 크게 세 과정으로 이루어진다.

1. Keygen: key generator G를 이용해 key pair (pk, vk)를 생성하는 과정
2. Prove: prover가 proof 를 생성하는 과정
3. Verify: verifier가 proof를 verifying하는 과정

1. Keygen: key generator G를 이용해 key pair (pk, vk)를 생성하는 과정

prover가 알고 있다고 주장하는 값인 witness(w) 가 있을 때, 이를 parameter로 받는 특정 program C가 있다고 하자. program C는 다음과 같다고 가정한다. (아래의 예는 가장 직관적이고 간결한 예시이며, 실제로 C의 세부적인 구현은 당연히 훨씬 더 복잡할 수 있다)

function C(x, w) {

return ( hash(w) == x) ;

}

위처럼 내가 w를 알고 있음을 증명할 수 있는 program C와 random sampling seed인 lambda를 generator에 parameter로 집어넣음으로써 key pair를 생성할 수 있다. 여기서 lambda는 prover 및 외부에 노출되어서는 안된다. 왜냐하면 prover가 이 값을 알고 있을 경우 fake proof를 생성할 수 있기 때문이다. 그렇기 때문에 key generating은 verifier가 수행하게 된다.

• G(C, lambda) = (pk, vk)
• pk = proving key
• vk = verifying key

C의 program size bound를 l, input(x) size의 bound를 n, execution time bound를 T라고 할 때, key generating의 시간 복잡도는

O (l + n + T) · log(l + n + T)

에 해당한다. 즉, program이 길고, input size가 크고, 실행 시간이 길수록, key generating에 소요되는 시간이 길다.

2. Prove: prover가 proof(prf)를 생성하는 과정

증명 알고리즘을 P, 증명하고자 하는 witness인 w, w의 hash를 x 라고 할 때, prf를 구하는 방법은 다음과 같다.

prf = P(pk, w, x)

prover는 prf를 계산한 후, prf만을 verifier에게 전달한다. prf을 계산하는 데 걸리는 시간은 입력값 x와 w의 크기에 비례하여 길어진다. prf가 계산된 이후에는 당연히prf로부터 w 값을 유추할 수 없으며, prf의 길이는 매우 짧다. 이는 기존의 ZKP가 갖지 못했던 간결함(succinctness)의 특성을 갖게 해주는 요소이다. 실제로 Eli의 논문에서 구현된 zk-SNARKs 구현체의 proof는 230바이트, 288바이트 정도로 매우 짧았다.

3. Verify: verifier가 prf를 verifying하는 과정

verifier는 prf를 prover로부터 전달 받은 후, verifying algorithm V를 수행하여 prf의 진위 여부를 판단한다. verifying에 걸리는 시간은 매우 짧은데, 이 역시 zk-SNARKs가 간결함의 특성을 가지는 요소 중 하나이다. 자세한 실험 결과는 역시 Eli의 논문에서 확인 가능하다.

boolean: V(vk, x, prf)

위 값이 TRUE이면 prover는 w 값을 정말로 알고 있다고 할 수 있고, FALSE이면 prover는 w 값을 속였다고 판단하게 된다.

위 3단계의 과정을 통해서 verifier는 prover의 knowledge를 직접 확인하지 않고 이를 빠른 시간에 verifying할 수 있게 된다.

Applications of zk-SNARKs

현재 다양한 field에서 zk-SNARKs를 이용한 application이 고안되고 있다. 아래에서 소개하는 예제는 대부분 이론적인 것으로, 실제로 구현되어 사용되는 application은 매우 적다는 것을 참고하기 바란다.

• Confidential Tx: Ethereum에서 transaction의 상세 내용을 숨기는 방식

zk-SNARKs를 이용하면 Ethereum에서 ETH를 송금하는 트랜잭션을 발생시킬 때, sender가 receiver에게 트랜잭션을 보낸 사실은 공개하고, sender와 receiver의 balance와 transfer amount에 대한 상세 내용을 숨기는 전송 방식이 가능하다.

• For Blockchain Scalability

zk-SNARKs를 이용하여 blockchain의 scalability를 해결할 수 있다는 아이디어가 많이 제시되고 있다. blockchain에 참여하는 client는 실제로 블록의 내용을 모르더라도 full node의 proof를 보고 해당 블록의 내용이 변조되지 않았음을 빠르게 verifying할 수 있다. 결국, 이는 client의 block sync 속도를 급격하게 높여주게 되어 새로운 client들이 빠르게 네트워크에 참여할 수 있게 된다.

또한, blockchain의 append-only 한 속성으로 blockchain의 용량은 시간이 지날수록 계속 커진다. 특히 Ethereum에서는 trie 형태의 여러 global data structure(state trie, transaction trie, receipt trie 등)가 쌓여가고 있다. 이 trie 구조에는 각종 smart contract의 code와 storage 등 여러 데이터들이 자리를 차지하고 있는데, zk-SNARKs를 통해 실제 데이터를 pruning하고 데이터에 대한 proof만 남기는 방식으로 압축시킴으로써 contract가 차지하는 공간을 획기적으로 줄일 수 있다. smart contract의 code와 storage를 체인 위에 공개하지 않으면서 state change를 증명하는 방법이 가능하기 때문이다.

• Zcash

zk-SNARKs는 Zcash Team에 의해 개발되었으며, zk-SNARKs 기반으로 작동하고 있는 application 중 가장 큰 규모이다. Zcash는 영지식 증명을 기반으로 완전히 익명화된 트랜잭션의 전송을 가능하게 한다. 기본적인 동작방식은 Bitcoin과 상당히 유사하나, 가장 두드러지는 차이점은 address의 종류가 2가지라는 것이다.

Shielded address와 Transparent address를 이용하여, 사용자들은 이 두 address를 사용하여 ZCash의 화폐인 ZEC를 공개적으로 전송할지, 사적으로 전송할지 선택할 수 있다. Shielded address에서 Transparent address로 송금을 하게 되면 전달받은 ZEC가 공개가 되며, 반대의 경우는 숨겨진다. ZCash는 두 주소 체계의 공존을 통해 자금 흐름의 추적을 거의 불가능하게 만들었고, 이는 ZCash가 익명 코인이라고 불리는 대표적인 이유 중 하나이다.

위에서 소개한 application 이외에도 zk-SNARKs는 블록체인이 당면하고 있는 여러 문제들을 해결할 수 있는 개념으로 다양한 분야에서 이용될 수 있을 것이다.

Conclusion

지금까지 zk-SNARKs에 관한 개괄적인 내용을 살펴보았다. zk-SNARKs는 암호학을 바탕으로 한 개념이기 때문에 이론 자체가 매우 어려워도 이를 잘 이해할 수 있다면, 응용할 수 있는 분야는 무궁무진할 것이라고 생각한다. 다음 글에서는 zk-SNARKs의 자세한 과정을 수학적 이론에 기반해서 조금 더 심도깊게 설명해보도록 하겠다.

References

1. https://blockgeeks.com/guides/what-is-zksnarks/
2. https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell/
3. https://chriseth.github.io/notes/talks/intro_to_zksnarks/#/1
4. http://crypto.fmf.ktu.lt/lt/xdownload/KS%20Pvz_Aurimas_Aurimaitis%20IF-3.3%20Schnorr_Ident%20Skaidres.pptx
5. https://ko.wikipedia.org/wiki/%EC%9D%B4%EC%82%B0_%EB%A1%9C%EA%B7%B8
6. https://eprint.iacr.org/2013/879.pdf
7. https://media.consensys.net/introduction-to-zksnarks-with-examples-3283b554fc3b
8. https://hackernoon.com/zksnarks-and-blockchain-scalability-af85e350a93a
9. https://z.cash/technology/index.html#how-it-works

Special thanks to Se Jin OH, Jihyeok Choy, Jeongho Jeon for reviewing.

다음글: chapter 2. Deep Dive into zk-SNARKs

Zero-Knowledge proof :: chapter 1. Introduction to Zero-Knowledge Proof & zk-SNARKs was originally published in Decipher Media ｜디사이퍼 미디어 on Medium, where people are continuing the conversation by highlighting and responding to this story.