안녕하세요, 재무 관리를 위한 롤업 디자인을 제안하고자 이 글을 작성합니다.
이더리움이 등장한 이후 DeFi는 상당한 발전을 이루었고, 프로그래밍 가능한 금융이라는 개념은 이미 현실이 되었습니다. 물론 항상 순탄했던 것은 아니며, 그 결과로 수십억 달러의 손실을 초래한 악용 사례들이 발생했습니다. 해결책으로 더 많은 감사와 더 나은 도구가 제시되었지만, 저는 DeFi 업계가 잘못된 부분을 패치하려고 애쓰고 있다고 생각합니다. 감사와 형식 검증 표준이 된 시점에 이르렀음에도 불구하고, 보안은 여전히 잘못된 부분을 패치하는 끝없는 싸움으로 남아 있습니다. 우리는 스마트 계약 악용을 예외적인 경우나 개발자 오류로 취급하지만, 이는 현재 실행 환경이 허용하는 예측 가능한 결과입니다.
핵심 주장
이더리움은 설계상 튜링 완전성을 갖도록 만들어졌습니다. 이러한 일반성은 강력하고 필수적이지만, 모든 사용 사례에 필요한 것일까요? 답은 '아니오'이며, 금융 시스템이 그 가장 명확한 예입니다.
금융은 언제나 제한된 규칙 체계 안에 존재해 왔습니다. 초기 곡물 대출부터 현대의 결제기관에 이르기까지, 지금까지 구축된 모든 금융 시스템은 본질적으로 제약 시스템이었습니다. 즉, 참여자, 자산, 매매 조건, 공식, 시간 범위가 명확하게 정의되어 있었습니다. 이러한 범위를 벗어나는 것은 허용되지도 않고 관련성도 없었습니다. 이는 변한 것이 없습니다. 달라진 것은 이러한 시스템을 구축하는 데 사용된 실행 환경입니다.
대부분의 DeFi 취약점은 금융 논리에서 비롯되는 것이 아닙니다. 오히려 그 주변의 임의적인 연산에서 비롯됩니다. 튜링 완전 환경에서 선언적 패턴을 구현하면, 해당 환경의 강력한 기능을 사용하지 않고도 전체 공격 표면을 그대로 물려받게 됩니다.
The DAO 해킹 사건이 가장 명확한 예입니다. 2016년, 재진입 취약점을 통해 360만 이더리움(ETH) 유출되었습니다. 근본적인 원인은 일반적인 의미의 개발자 오류가 아니었습니다. 이는 제약이 있는 금융 시스템을 제약이 없는 실행 계층에 배포했을 때 발생할 수 있는 예측 가능한 결과였습니다.
function withdraw(uint256 _amount) external {require(balances[msg.sender] >= _amount, "Insufficient balance");(bool sent, ) = msg.sender.call{value: _amount}("");require(sent, "Failed to send Ether");balances[msg.sender] -= _amount; // state updated after external call}출금 기능은 잔액을 업데이트하기 전에 이더리움(ETH) 전송했습니다. 이더리움 가상 머신(EVM) 재진입 호출을 허용하므로 공격자는 잔액이 감소하기 전에 출금 함수를 재귀적으로 호출할 수 있습니다. FVL에서 이에 해당하는 내용은 다음과 같습니다.
system: "DAO" pool: collect: from: type: anyone what: type: eth rules: conditions: - if: type: balance_gte value: "1" then: type: enable permission: withdraw distribute: formula: type: proportional to: type: contributors triggers: manual rights: anyone: [ deposit , view ] contributors: [ withdraw ]FVL에서는 그러한 유형의 버그가 재진입 방지 장치를 추가하거나 로직 순서를 재배열하는 것이 아니라, 실행 환경 자체가 애초에 그러한 상태 전환이 발생하는 것을 허용하지 않기 때문에 완전히 제거됩니다.
경계
제 제안은 명확한 경계를 긋습니다.
금융 시스템을 알려진 기본 요소에 대한 결정론적 상태 전환을 통해 처음부터 끝까지 설명할 수 있다면 FVL에 속합니다. 실행 전에 값을 알 수 없는 임의의 계산이 필요한 경우 이더리움에 속합니다.
아베(AAVE) 와 Compound처럼 복잡성 때문에 범용 컴퓨팅이 진정으로 필요한 프로토콜은 소수이지만, 이러한 프로토콜들은 합법적인 범주에 속합니다.
원시 집합
근본적으로 모든 금융 시스템은 다섯 가지 기본 요소로 구성됩니다.
system: <string> # System name pool: <config> # Asset collection rules rules: <config> # Conditional logic and distributions rights: <map> # Permission definitions time: <config> # Temporal constraints oracles: <list> # External data feeds이러한 기본 요소들을 조합하면 다음과 같은 결과가 나옵니다.
- 대출 풀:
pool + rights + oracles + rules - 스테이킹 풀:
pool + time + rights - 크라우드펀딩:
pool + time + rules + rights - 분산형 자율 조직(DAO):
pool + rights + rules + oracles + time
실제 작동하는 예시로 커뮤니티 스테이킹 시스템을 들 수 있습니다.
system: "CommunityStaking" pool: collect: from: type: token_holders address: "0xYourToken" what: type: erc20 address: "0xStakingToken" min: type: value amount: "100" cap: type: value amount: "1000000" rules: conditions: - if: type: time_gt timestamp: "1735689600" then: type: enable permission: withdraw distribute: formula: type: proportional to: type: contributors triggers: continuous time: locks: type: duration seconds: "2592000" vesting: type: linear duration: "7776000" rights: contributors: [ stake , unstake ] admin: [ pause , update_params ] oracles: []실행 모델
모든 FVL 시스템은 유한 상태 기계입니다. 이것이 FVL의 보안 및 검증 가능성 속성이 기반을 두고 있는 원리입니다.
결정론 :
전환 함수는 실행 중에 외부 상태를 읽지 않습니다. 동일한 초기 상태와 동일한 순서의 거래 시퀀스가 주어지면, 어떤 두 당사자라도 동일한 결과에 도달합니다. 상태 전환은 완전히 제한적이며 실행 중에 어떠한 간섭도 불가능합니다.
종료 :
모든 트랜잭션은 O(k) 시간 내에 종료됩니다. 여기서 k는 시스템 배포 시 정의된 조건의 수입니다. k는 배포 시 고정되며 변경될 수 없습니다. 실행 비용은 완벽하게 예측 가능하며, 서비스 거부 공격 벡터의 전체 유형이 존재하지 않습니다.
제한된 공격 표면 :
입력 알파벳은 유형이 지정되어 있으며 유한합니다. 임의의 함수를 호출하거나, 선언되지 않은 오라클을 참조하거나, 정의된 기본 요소 집합 범위를 벗어나는 동작을 유발하는 트랜잭션을 제출할 수 없습니다.
재플레이 가능성 :
전환 함수가 결정론적이고 모든 입력값이 추가 전용 로그에 기록되므로 현재 상태를 항상 처음부터 재구성할 수 있습니다. 로그에 접근할 수 있는 사람은 누구나 보고된 상태가 정확한지 독립적으로 확인할 수 있습니다.
건축
FVL은 이더리움 메인넷에 정착하는 옵티미스틱 롤업 으로, 이더리움 가상 머신(EVM) 실행 환경을 목적에 맞게 설계된 제약 조건이 있는 런타임으로 대체합니다.
┌─────────────────────────────────────────┐│ Declaration Layer (YAML) ││ parsing, validation, System ID │└─────────────────┬───────────────────────┘▼┌─────────────────────────────────────────┐│ Execution Layer — FVL Runtime ││ deterministic state transitions, ││ block production, state roots │└─────────────────┬───────────────────────┘▼┌─────────────────────────────────────────┐│ Settlement Layer — Ethereum L1 ││ state root anchoring, data ││ availability, fraud proof adjudication │└─────────────────────────────────────────┘배포된 각 시스템은 콘텐츠 주소 지정 방식의 시스템 ID로 식별됩니다.
system_id = Keccak256(canonical_json(system))
정의, 필드, 조건, 권한 등 어떤 부분이든 변경되면 다른 ID가 생성됩니다. 중복 배포는 프로토콜 수준에서 거부됩니다. 배포자를 신뢰하지 않고도 누구나 로컬에서 배포된 시스템이 예상하는 정의와 일치하는지 확인할 수 있습니다.
기본 확장(FIP)
기본 요소 집합은 의도적으로 유한합니다. 이것이 안전성을 보장하는 핵심입니다. 새로운 기본 요소는 이더리움의 이더리움 개선 제안(EIP) 프로세스를 모델로 한 FVL 개선 제안을 통해 추가됩니다.
수용 기준은 단 하나의 질문입니다. 이 기본 요소를 튜링 완전성 없이 구현할 수 있을까요?
만약 그렇다면, 포함 대상 후보가 됩니다. 그렇지 않다면, 해당 사용 사례는 이더리움 자체에 속해야 합니다. 이 경계는 매우 중요합니다. 예외적인 상황을 처리하기 위해 일반적인 연산 기능을 추가한 FVL 버전은 정적 분석 기능, 간단한 사기 증명 검증기, 그리고 제한된 실행 보장 기능을 잃게 됩니다.
추가 자료
FVL이 무엇인지에 대한 더 자세한 내용과 간단한 구현 예시를 보시려면 아래를 참조하세요.
