Compound on Jeongseup Blog

Lending Protocol Study Day 2: Compound V2 Deep Dive와 Aave V3 아키텍처

Wed, 25 Feb 2026 00:00:00 +0000

7일간의 DeFi Lending Protocol 스터디 시리즈. Day 2에서는 Compound V2의 내부 구조를 코드 레벨로 파고들고, 렌딩 프로토콜의 3가지 유형을 분류한 뒤, Aave V3의 아키텍처 진화를 분석한다.

Repository: jeongseup/lending-protocol-study

Day 2 목표

Compound V2의 CToken 상속 구조와 “Fresh” 패턴을 코드 레벨로 이해한다
Mantissa 기반 고정소수점 연산과 Lazy Interest Accrual 메커니즘을 파악한다
렌딩 프로토콜을 3가지 유형(Pool-based, CDP-based, Fixed-rate)으로 분류한다
Aave V3의 비트맵 스토리지 최적화와 아키텍처 진화를 분석한다

Compound V2 Deep Dive: CToken 상속 구조

Day 1에서 Compound V2의 핵심 파일 3개를 언급했다. Day 2에서는 CToken의 상속 구조부터 파고든다.

1
2
3
4


CTokenInterface (인터페이스)
 └─ CToken (핵심 로직)
 ├─ CErc20 (ERC20 자산용 - USDC, DAI 등)
 └─ CEther (ETH 전용)

CErc20과 CEther의 차이는 단순하다. ETH는 ERC20이 아니라 msg.value로 받아야 하므로, 자금 수수 로직만 다르고 핵심 렌딩 로직은 CToken에 모두 있다.

중요한 건 CToken이 풀 역할까지 겸한다는 점이다. mint(), borrow(), repay(), liquidate() 모두 CToken 컨트랙트에 있다. 하나의 컨트랙트가 ERC20 토큰이면서 동시에 렌딩 풀인 Monolithic 구조다.

Fresh 패턴: “이자부터 정산하고 본론으로”

Compound V2의 모든 핵심 함수 이름에 Fresh가 붙어 있다.

1
2
3
4


function mintFresh(address minter, uint mintAmount) internal
function borrowFresh(address payable borrower, uint borrowAmount) internal
function repayBorrowFresh(address payer, address borrower, uint repayAmount) internal
function liquidateBorrowFresh(address liquidator, address borrower, ...) internal

왜 Fresh일까? **“이자를 최신 상태로 정산한 뒤에 핵심 로직을 실행한다”**는 패턴이다.

1
2
3
4


function mint(uint mintAmount) external returns (uint) {
 accrueInterest(); // 1. 이자 먼저 정산
 return mintFresh(msg.sender, mintAmount); // 2. 그 다음 본론
}

모든 external 함수가 이 패턴을 따른다:

1

사용자 호출 → accrueInterest() → xxxFresh() → 실제 로직

이렇게 하는 이유는 간단하다. 이자 계산은 마지막 업데이트 이후의 블록 수에 기반한다. 이자를 정산하지 않고 mint()을 실행하면, 기존 예치자들의 교환비율이 부정확한 상태에서 새로운 지분이 발행되어 기존 예치자가 손해를 본다.

Mantissa: Solidity의 소수점 해법

Solidity에는 부동소수점이 없다. Compound V2는 이를 Mantissa 방식으로 해결한다.

$$\text{Mantissa} = \text{실제값} \times 10^{18}$$

예를 들어:

이자율 5% → 0.05 × 10^18 = 50000000000000000
교환비율 0.02 → 0.02 × 10^18 = 20000000000000000

곱셈과 나눗셈 시 스케일링을 맞춰야 한다:

1
2
3
4
5
6
7
8


// 두 Mantissa 값의 곱셈: 결과를 10^18으로 나눠서 스케일 복원
function mulScalar(Exp memory a, uint scalar) pure internal returns (Exp memory) {
 return Exp({mantissa: a.mantissa * scalar});
}

function mulExp(Exp memory a, Exp memory b) pure internal returns (Exp memory) {
 return Exp({mantissa: a.mantissa * b.mantissa / 1e18});
}

이 패턴은 Compound만의 것이 아니다. Aave의 RAY(10^27), Uniswap V3의 Q96(2^96), MakerDAO의 WAD(10^18) 모두 같은 원리다. 정수로 소수점을 표현하기 위한 고정소수점 연산.

Lazy Interest Accrual: 이자는 “필요할 때만” 계산한다

accrueInterest()는 매 블록마다 자동으로 실행되는 게 아니다. 누군가 트랜잭션을 보낼 때만 실행된다. 이것이 Lazy Evaluation이다.

1
2
3


블록 100: Alice가 mint() → accrueInterest() 실행 (블록 0~100 이자 계산)
블록 200: 아무 일 없음 → 이자 계산 안 함
블록 300: Bob이 borrow() → accrueInterest() 실행 (블록 100~300 이자 계산)

200 블록 동안 아무도 상호작용하지 않으면, 200 블록치의 이자가 한번에 계산된다. 가스비는 트랜잭션 수가 아니라 상호작용 빈도에 비례한다.

accrueInterest()가 업데이트하는 상태 변수는 딱 4개다:

1
2
3
4


totalBorrows // 총 대출량 (이자 포함)
totalReserves // 프로토콜 수익 누적
borrowIndex // 대출자 이자 추적용 전역 인덱스
accrualBlockNumber // 마지막 이자 정산 블록 번호

4개의 SSTORE = 20,000 gas. 사용자 수가 아무리 많아도 이 비용은 고정이다. 이것이 Day 1에서 설명한 Scaled Balance 패턴의 실제 구현이다.

이자 시나리오 시뮬레이션

구체적인 숫자로 따라가보자.

초기 상태

1
2
3
4
5
6


블록 0: Pool에 10,000 USDC
- totalCash = 10,000
- totalBorrows = 0
- totalReserves = 0
- borrowIndex = 1.0 (1e18)
- exchangeRate = 10,000 / 500,000 = 0.02 (cToken 500,000개 발행 가정)

Alice가 1,000 USDC 대출

1
2
3
4
5


블록 100: Alice borrow(1,000)
- accrueInterest() 실행 (totalBorrows = 0이므로 이자 없음)
- totalCash = 9,000 (1,000 빠짐)
- totalBorrows = 1,000
- Alice의 borrowSnapshot = {principal: 1,000, interestIndex: 1.0}

100블록 후 이자 정산

1
2
3
4
5
6
7


블록 200: Bob이 mint() 호출
- 이자율: borrowRate = 0.0001/블록 (연 약 5.3%)
- 경과 블록: 100
- simpleInterestFactor = 0.0001 × 100 = 0.01
- 새 totalBorrows = 1,000 × 1.01 = 1,010
- Reserve Factor 10%: 새 totalReserves = 10 × 0.1 = 1
- 새 borrowIndex = 1.0 × 1.01 = 1.01

Alice의 실제 대출 잔액은?

$$\text{Alice 대출잔액} = \frac{\text{principal} \times \text{현재 borrowIndex}}{\text{Alice의 interestIndex}} = \frac{1{,}000 \times 1.01}{1.0} = 1{,}010 \text{ USDC}$$

Alice의 Storage를 건드리지 않고도 전역 borrowIndex 하나만으로 정확한 잔액을 계산했다.

렌딩 프로토콜의 3가지 유형

Day 1에서는 Pool-based 모델만 다뤘다. 실제로 렌딩 프로토콜은 자금 조달 방식에 따라 3가지로 분류된다.

1. Pool-based (Compound, Aave)

1

예치자 → [Pool] → 차입자

기존 예치금에서 대출
예치자가 없으면 빌릴 수 없다
이자율은 Utilization Rate에 연동

2. CDP-based (MakerDAO)

1

사용자 → [Vault] → 새 DAI 발행

프로토콜이 새 토큰을 발행 (mint)
예치자 없이도 대출 가능
Stability Fee(이자)는 거버넌스가 결정
CDP = Collateralized Debt Position

3. Fixed-rate (Yield Protocol)

1

사용자 → fyToken (만기 시 1:1 교환 가능)

할인된 미래 가치 토큰 매매
0.95 fyUSDC를 사면, 만기에 1 USDC → 약 5% 고정 금리
이자율이 트레이딩으로 결정

비교 정리

특성	Pool-based	CDP-based	Fixed-rate
자금 출처	예치자	프로토콜 발행	시장 매매
이자율 결정	알고리즘 (사용률)	거버넌스 투표	시장 수급
변동/고정	변동	반고정	고정
대표	Compound, Aave	MakerDAO	Yield, Notional
필요 조건	유동성 공급자	없음 (mint)	만기 매칭

대부분의 메이저 프로토콜이 Pool-based인 이유: 구현이 단순하고, 유동성이 자연스럽게 형성되기 때문이다. CDP는 토큰 경제 설계가 복잡하고, Fixed-rate는 만기 매칭이 어렵다.

Aave V3 아키텍처: Compound에서 무엇이 진화했나

Compound V2는 CToken이 모든 걸 한다. Aave V3는 이를 분리했다.

1
2
3
4
5
6
7


Compound V2:
 사용자 → CToken.mint() (CToken = 풀 + 토큰)

Aave V3:
 사용자 → Pool.supply() (Pool = 라우터)
 → SupplyLogic.executeSupply() (Library = 실제 로직)
 → aToken.mint() (aToken = 순수 영수증)

delegatecall + Library 패턴

Aave V3의 Pool.sol은 얇은 프록시에 가깝다. 실제 로직은 Library 컨트랙트에 있다.

1
2
3
4
5
6
7
8


// Pool.sol
function supply(address asset, uint256 amount, ...) external {
 SupplyLogic.executeSupply(...); // delegatecall로 Library 호출
}

function borrow(address asset, uint256 amount, ...) external {
 BorrowLogic.executeBorrow(...);
}

Library를 쓰면:

코드 크기 제한(24KB) 회피 - Pool의 로직이 아무리 커도 Library에 분산
관심사 분리 - Supply, Borrow, Liquidation 로직이 독립적으로 관리
단, Library는 독립 배포 후 업그레이드 불가 - Proxy 패턴과 조합하여 해결

Debt Tokenization

Compound V2에서 대출은 단순 매핑이다:

1
2


// Compound V2
mapping(address => BorrowSnapshot) accountBorrows;

Aave V3는 대출도 토큰화했다:

1
2
3


// Aave V3
variableDebtToken.mint(borrower, amount); // 대출하면 부채 토큰 발행
variableDebtToken.burn(borrower, amount); // 상환하면 부채 토큰 소각

부채를 토큰화하면 무엇이 좋은가?

balanceOf()로 대출 잔액 조회 가능 (표준 인터페이스)
Transfer 제한으로 부채 이전 방지
이벤트 표준화 (Transfer 이벤트로 대출/상환 추적 가능)

Aave V3.2부터 Stable Rate이 제거되었다. 변동금리만 남았으므로 stableDebtToken은 더 이상 사용되지 않는다.

비트맵 스토리지 최적화

Day 2의 가장 중요한 기술적 발견이다. Compound V2와 Aave V3의 사용자 상태 관리 방식이 근본적으로 다르다.

Compound V2: 배열 순회

1
2
3
4
5
6
7


// Comptroller.sol
mapping(address => CToken[]) public accountAssets; // 사용자별 참여 마켓 배열

// Health Factor 계산 시
for (uint i = 0; i < assets.length; i++) {
 // 모든 마켓을 순회하며 담보 가치 합산
}

문제: 사용자가 참여한 마켓이 많을수록 가스비가 선형으로 증가한다.

Aave V3: 비트맵

1
2
3
4
5
6
7


// 하나의 uint256에 128개 자산의 상태를 담는다
// 각 자산이 2비트를 차지: [담보 사용 여부][대출 여부]
mapping(address => UserConfigurationMap) internal _usersConfig;

struct UserConfigurationMap {
 uint256 data; // 256비트 = 128개 자산 × 2비트
}

비트맵의 구조:

1
2
3
4
5


비트 위치: ... | 5 | 4 | 3 | 2 | 1 | 0 |
자산 ID: | 2 | 1 | 0 |
의미: ... | C | B | C | B | C | B |
 B = Borrowing (대출 중)
 C = Collateral (담보로 사용 중)

Health Factor 계산 시:

1
2
3
4


// 비트맵에서 해당 비트가 0이면 스킵
if (userConfig.data & (1 << (reserveIndex * 2)) == 0) {
 continue; // 이 자산은 대출도 담보도 아님 → O(1)로 스킵
}

성능 비교

1
2
3
4
5


Compound V2 (배열):
 10개 마켓 참여 → 10번 SLOAD + 루프 = ~50,000 gas

Aave V3 (비트맵):
 128개 마켓 확인 → 1번 SLOAD + 비트 연산 = ~2,100 gas

비트 연산(AND, SHIFT)은 3 gas다. 128개 자산을 확인해도 2,100 + 128 × 3 = 2,484 gas. 배열 방식 대비 약 20배 절약이다.

이 차이가 결정적인 이유: Health Factor 계산은 모든 트랜잭션에서 발생한다. supply, borrow, repay, liquidate 전부. 가장 빈번하게 호출되는 로직의 가스를 20배 줄이면 프로토콜 전체의 가스 효율이 극적으로 개선된다.

LendingPool 리팩토링: 배운 것을 적용하기

스터디 프로젝트의 LendingPool.sol에 Aave V3의 PoolStorage 패턴을 적용했다.

Before: 단순 매핑

1
2


mapping(address => mapping(address => uint256)) public deposits;
mapping(address => mapping(address => uint256)) public borrows;

After: 구조화된 스토리지

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


struct ReserveData {
 uint128 liquidityIndex;
 uint128 variableBorrowIndex;
 uint128 currentLiquidityRate;
 uint128 currentVariableBorrowRate;
 uint40 lastUpdateTimestamp;
 uint16 id;
 address aTokenAddress;
 address variableDebtTokenAddress;
 uint128 totalDeposits;
 uint128 totalBorrows;
}

mapping(address => ReserveData) internal _reserves;
mapping(uint256 => address) internal _reservesList;
uint16 internal _reservesCount;

mapping(address => UserConfigurationMap) internal _usersConfig;

핵심 변경점:

_reserves: 자산 주소 → ReserveData 매핑 (모든 자산 상태를 하나의 구조체로)
_reservesList: reserveId → 자산 주소 매핑 (비트맵 인덱싱용)
_usersConfig: 사용자별 비트맵 (담보/대출 상태)

비트맵 헬퍼도 구현했다:

1
2
3
4
5
6
7
8
9


function isUsingAsCollateral(UserConfigurationMap memory self, uint256 reserveIndex)
 internal pure returns (bool) {
 return (self.data >> (reserveIndex * 2 + 1)) & 1 != 0;
}

function isBorrowing(UserConfigurationMap memory self, uint256 reserveIndex)
 internal pure returns (bool) {
 return (self.data >> (reserveIndex * 2)) & 1 != 0;
}

리팩토링 후 모든 62개 테스트(기존 61 + 비트맵 테스트 1)가 통과했다.

JumpRateModel 테스트: Fuzz Testing까지

Day 1에서 이론으로 다룬 JumpRateModel을 실제로 구현하고 테스트했다.

Unit Test: 18개 케이스

1
2
3
4
5
6


[PASS] testGetBorrowRate_ZeroUtilization()
[PASS] testGetBorrowRate_AtKink()
[PASS] testGetBorrowRate_AboveKink()
[PASS] testGetBorrowRate_FullUtilization()
[PASS] testGetSupplyRate_WithReserveFactor()
... (18개 전부 통과)

Fuzz Test: 6개 케이스

1
2
3
4
5
6
7
8
9


function testFuzz_BorrowRateMonotonicity(uint256 util1, uint256 util2) public {
 util1 = bound(util1, 0, 1e18);
 util2 = bound(util2, util1, 1e18);

 uint256 rate1 = model.getBorrowRate(cash1, borrows1, reserves1);
 uint256 rate2 = model.getBorrowRate(cash2, borrows2, reserves2);

 assertGe(rate2, rate1); // 사용률이 높으면 이자율도 높아야 한다
}

Fuzz Testing으로 검증한 불변 조건:

단조 증가: 사용률이 올라가면 이자율도 올라간다
Supply ≤ Borrow: Supply Rate은 항상 Borrow Rate 이하
Kink에서의 연속성: kink 전후로 이자율이 비연속적으로 뛰지 않는다

전체 24개 테스트 (18 unit + 6 fuzz) 모두 통과.

Day 2 핵심 인사이트 정리

Fresh 패턴은 렌딩의 정합성을 보장한다 - 이자를 먼저 정산하지 않으면 교환비율이 부정확해져서 기존 사용자가 손해본다. “이자부터, 그 다음 본론"이 원칙.
Lazy Interest Accrual은 가스 효율의 핵심 - 매 블록이 아니라 트랜잭션이 발생할 때만 이자를 계산한다. 4개의 SSTORE로 전체 사용자의 이자를 한번에 정산.
렌딩은 3가지 유형 - Pool-based(예치금에서 빌림), CDP-based(새 토큰 발행), Fixed-rate(할인 토큰). 대부분이 Pool-based인 이유는 구현 단순성과 유동성 형성의 용이함.
비트맵이 아키텍처를 결정한다 - Compound의 배열 vs Aave의 비트맵. 한 번의 SLOAD로 128개 자산 상태를 확인하는 것은 단순한 최적화가 아니라, Health Factor 계산이 모든 트랜잭션에서 발생하기 때문에 프로토콜 전체 가스 효율을 좌우한다.
Storage 레이아웃이 아키텍처를 결정한다 - Compound는 배열 중심이라 Monolithic이 자연스럽고, Aave는 비트맵 + 구조체 중심이라 Modular가 자연스럽다. 데이터 구조가 코드 구조를 결정한다.

Next: Day 3

내일은 청산(Liquidation) 메커니즘을 파고든다.

청산 트리거 조건과 liquidateBorrowFresh() 코드 리딩
청산 보너스(Liquidation Incentive) 경제학
Foundry Fork Testing으로 Aave V3 메인넷 청산 시뮬레이션
고급 Foundry 테스팅 패턴 (invariant, fork)

이 시리즈의 전체 코드와 학습 자료는 lending-protocol-study 레포에서 확인할 수 있다.

Lending Protocol Study Day 1: DeFi 렌딩의 핵심 개념과 아키텍처

Mon, 23 Feb 2026 00:00:00 +0000

7일간의 DeFi Lending Protocol 스터디 시리즈. 백엔드/인프라 엔지니어 관점에서 렌딩 프로토콜을 코드 레벨까지 파헤친다.

Repository: jeongseup/lending-protocol-study

Why Lending Protocol?

블록체인 인프라 엔지니어로 일하면서 노드 운영, 밸리데이터 모니터링, 스테이킹 보상 분석 등을 해왔다. 그런데 DeFi의 가장 큰 축인 렌딩 프로토콜은 “대충 알겠는데 코드 레벨에서는 모른다"는 상태였다.

이번 스터디의 목표는 명확하다:

Compound V2 / Aave V3의 핵심 로직을 코드로 읽고 구현한다
렌딩의 수학적 모델(이자율, 청산, Health Factor)을 공식 수준으로 이해한다
Solidity + Go 모니터링 도구까지 만들어 실무에 적용 가능한 수준으로 올린다

렌딩 프로토콜의 본질: 풀 기반 중개

전통 금융의 대출은 대출자와 차입자를 1:1로 매칭한다. DeFi 렌딩은 다르다.

1
2


전통 금융: Alice → [은행] → Bob (1:1 매칭)
DeFi 렌딩: Alice → [Pool] ← Bob (풀 기반 간접 매칭)

예치자들이 자산을 풀에 넣으면, 차입자들이 담보를 걸고 풀에서 빌려간다. 아무도 누가 누구에게 빌려줬는지 모른다. 이자율은 풀의 사용률(Utilization Rate)에 따라 알고리즘이 자동으로 결정한다.

이 구조의 핵심 이유는 간단하다:

1

블록체인 = 익명 → 신용평가 불가 → 담보로만 판단 → 과담보 필수

신용이 없으니 담보로 대체한다. 그래서 DeFi 렌딩은 태생적으로 과담보(Over-collateralized) 구조다.

렌딩의 5대 핵심 파라미터

렌딩 프로토콜을 이해하려면 이 5가지 숫자만 확실히 알면 된다.

파라미터	의미	일반적 범위
LTV (Loan-to-Value)	담보 대비 얼마까지 빌릴 수 있나	75-80%
Health Factor	내 포지션이 안전한가 (< 1이면 청산)	1.0 이상 유지
Utilization Rate	풀의 자금 중 얼마가 빌려졌나	이자율 결정
Reserve Factor	프로토콜이 이자에서 떼가는 비율	10-35%
Collateral Factor	자산의 담보 가치 인정 비율	자산마다 다름

외워야 할 공식 3개

$$HF = \frac{LT}{LTV}$$$$\text{최대 허용 하락률} = 1 - \frac{LTV}{LT}$$$$\text{Supply APY} = \text{Borrow APR} \times \text{Utilization} \times (1 - \text{Reserve Factor})$$

세 번째 공식이 특히 중요하다. Supply APY가 Borrow APR보다 수학적으로 항상 작은 이유가 여기 있다. 풀의 돈이 100% 빌려진 게 아니고(Utilization < 1), 프로토콜이 Reserve Factor만큼 떼가기 때문이다.

단, 토큰 인센티브(COMP, AAVE)나 포인트/에어드랍까지 포함하면 역전될 수 있다. 2020년 DeFi Summer에 “빌리면 돈 버는” 상황이 실제로 발생했다.

이자율 모델: Jump Rate Model

“사용률이 올라가면 이자율도 올라간다"는 단순한 원칙이지만, 구현 방식은 프로토콜마다 다르다.

프로토콜	모델	특징
Compound V2	Jump Rate Model	원조. kink 지점에서 이자율 급등
Aave V3	Variable Rate Strategy	비슷하지만 파라미터 구조 다름
MakerDAO	거버넌스 직접 설정	알고리즘 아님
Euler V2	모듈형	풀 생성자가 모델 직접 선택

DEX에서 x * y = k (CPMM)가 원조 모델이듯, 렌딩에서는 Jump Rate Model이 원조다. “유일한 표준"은 아니지만, 대부분의 모델이 이걸 변형한 것이다.

cToken vs aToken: 이자를 반영하는 두 가지 방법

렌딩에 자산을 예치하면 “영수증 토큰"을 받는다. 이 영수증이 이자를 반영하는 방식이 Compound와 Aave에서 근본적으로 다르다.

Compound의 cToken: 교환비율 상승

1
2
3


예치: 1,000 USDC → 50,000 cUSDC (교환비율 0.02)
1년후: 50,000 cUSDC 그대로, 교환비율 0.025로 상승
인출: 50,000 × 0.025 = 1,250 USDC

토큰 수량은 변하지 않고, 교환비율이 올라간다.

Aave의 aToken: 잔고 자동 증가 (Rebase)

1
2
3


예치: 1,000 USDC → 1,000 aUSDC (1:1)
1년후: 지갑에 1,050 aUSDC로 자동 증가
인출: 1,050 aUSDC → 1,050 USDC

교환비율은 1:1 고정이고, 토큰 수량이 늘어난다.

비교	cToken	aToken
UX	비직관적 (교환비율 계산 필요)	직관적 (잔고 = 실제 가치)
DeFi 호환성	유리 (표준 ERC20)	불리 (rebase 토큰)
수학	`amount = shares × exchangeRate`	`balance = scaledBalance × index`

수학적으로는 동일하다. “언제 곱하느냐"의 차이일 뿐이다.

cToken의 교환비율 패턴은 사실 DeFi 전반에서 반복되는 범용 패턴이다.

1

지분으로 변환 → 전역 비율만 업데이트 → 인출 시 역변환

이 패턴을 쓰는 곳들:

프로토콜	용도
Compound cToken	렌딩 예치 영수증
ERC-4626	토큰화된 Vault 표준
Lido wstETH	Liquid Staking
Rocket Pool rETH	Liquid Staking
Walrus StakingPool	스토리지 네트워크 스테이킹

Walrus의 StakingPool과 비교하면:

1
2
3
4
5
6
7
8
9


Compound cToken:
 exchange_rate = (totalCash + totalBorrows - totalReserves) / totalSupply
 deposit: shares = amount / exchange_rate
 withdraw: amount = shares × exchange_rate

Walrus StakingPool:
 exchange_rate = total_wal / total_shares
 stake: shares = principal × total_shares / total_wal
 withdraw: amount = shares × total_wal / total_shares

같은 공식이다. 변수명만 다르다.

가스 최적화의 핵심: Scaled Balance

aToken이 “잔고가 자동으로 늘어난다"면, 매번 모든 사용자의 잔고를 업데이트하는 걸까? 당연히 아니다. 그러면 가스비가 폭발한다.

핵심 아이디어: 쓰기를 읽기로 바꾼다.

1

Scaled Balance = 예치금 / 예치 시점의 liquidityIndex

이 값은 한번 저장되면 절대 변하지 않는다. 변하는 건 전역 liquidityIndex 하나뿐이다.

잔고를 조회할 때 scaledBalance × 현재 index로 계산한다. balanceOf()는 view 함수이므로 가스비가 0이다.

1
2
3
4
5
6


순진한 방식: 이자 발생 시 모든 사용자 잔고 SSTORE
 → 1,000명 × 5,000 gas = 5,000,000 gas

Scaled Balance: 전역 index 1개만 SSTORE
 → 5,000 gas
 → 99.9% 절약

EVM에서 SSTORE(쓰기)는 5,000 gas, MUL(곱셈)은 5 gas다. 쓰기는 계산보다 1,000배 비싸다. Merkle Patricia Trie를 재계산하고 모든 노드에 영구 저장해야 하기 때문이다. Scaled Balance는 이 비용 구조를 정확히 활용한 최적화다.

Compound V2 vs Aave V3: 아키텍처 차이

두 프로토콜의 가장 큰 차이는 코드 구조에 있다.

1
2
3
4
5


Compound: CToken이 풀 역할까지 겸함 (Monolithic)
 사용자 → CToken.mint()

Aave/우리 프로젝트: Pool과 토큰 분리 (Modular)
 사용자 → Pool.deposit() → aToken.mint()

Compound의 CToken은 ERC20 토큰이면서 동시에 렌딩 풀이다. mint(), borrow(), repay(), liquidate() 모두 CToken 컨트랙트에 있다. 반면 Aave는 Pool이 중심이고 aToken은 순수한 영수증 토큰이다.

Compound V2 코드 리딩 가이드

Compound V2 코드를 읽고 싶다면, 핵심 3개 파일, 5개 함수만 보면 된다.

CToken.sol - 핵심 함수 5개:

accrueInterest() - 이자 누적 (borrowIndex = scaled balance 패턴)
mintFresh() - 예치
borrowFresh() - 대출
repayBorrowFresh() - 상환
liquidateBorrowFresh() - 청산

Comptroller.sol - 핵심 함수 1개:

getHypotheticalAccountLiquidityInternal() - Health Factor 계산

BaseJumpRateModelV2.sol - 이자율 모델

나머지(Governance, Lens, Timelock 등)는 렌딩 로직과 무관하므로 무시해도 된다.

이자율의 3개 레이어

DeFi에서 실제 수익률은 단순한 이자율이 아니라 3개 레이어의 합이다.

1
2
3


Layer 1: 기본 이자 → Jump Rate Model이 결정
Layer 2: 토큰 인센티브 → COMP, AAVE 등 거버넌스 토큰 보상
Layer 3: 포인트/에어드랍 → Blast, EigenLayer 등

Layer 2, 3까지 포함하면 “빌리면 돈 버는” 상황도 발생한다. 2020 DeFi Summer에 COMP 보상이 대출 이자보다 커서 Compound에서 빌리는 것 자체가 수익이었던 것이 대표적인 사례다.

Day 1 핵심 인사이트 정리

렌딩의 본질은 풀 기반 중개 - 예치자와 대출자를 직접 매칭하지 않고, 풀을 통해 간접 매칭한다. 스테이킹 풀과 동일한 패턴.
Share-Based Accounting은 DeFi의 범용 패턴 - cToken, ERC-4626, wstETH, rETH, Walrus 전부 같은 원리. “지분으로 변환 → 전역 비율만 업데이트 → 인출 시 역변환.”
가스 최적화의 핵심은 “쓰기를 읽기로 바꾸기” - SSTORE는 계산보다 1,000배 비싸다. Scaled Balance 패턴으로 전역 index 하나만 업데이트하고 나머지는 읽기 시점에 계산.
Compound는 Monolithic, Aave는 Modular - CToken이 풀 겸 토큰 vs Pool과 토큰 분리.
실제 수익률 = 기본 이자 + 토큰 인센티브 + 포인트 - 3개 레이어를 모두 봐야 DeFi의 실제 경제를 이해할 수 있다.

Next: Day 2

내일은 Aave V3 아키텍처를 코드 레벨로 들어간다.

Pool.sol, SupplyLogic.sol, BorrowLogic.sol, LiquidationLogic.sol 리딩
Fork Testing으로 Aave V3 메인넷 상태에서 직접 테스트
Fuzz Testing으로 이자율 엣지 케이스 탐색