새로운 형태의 상태를 생성하여 상태를 초확장합니다.

Guillaume Ballet, Marius van der Wijden, Jialei Rong, CPerezz, Han, soispoke, Justin Drake, Maria Silva, Anders Elowsson 님께 피드백과 검토에 대해 특별히 감사드립니다.

향후 5년간 이더리움의 확장성을 확보하기 위해서는 실행 (이더리움 가상 머신(EVM) 연산, 서명 검증 등), 데이터 (트랜잭션 발신자, 수신자, 서명, 호출 데이터 등), 상태 (계정 잔액, 코드, 저장소)라는 세 가지 자원을 확장해야 합니다. 우리의 목표는 이더리움을 약 1000배까지 확장하는 것입니다. 하지만 이 세 가지 자원 중 처음 두 가지와 세 번째 자원 사이에는 근본적인 비대칭성이 존재합니다.

숏 으로는 세 가지 자원 모두의 효율성을 높일 수 있습니다. 하지만 장기적으로 원하는 1000배의 효율성 향상을 달성하려면 마법 같은 해결책이 필요합니다. ZK-EVM은 실행 부문의 마법 같은 해결책이고, PeerDAS는 데이터 부문의 마법 같은 해결책입니다. 하지만 상태 관리에는 마법 같은 해결책이 없습니다. 그렇다면 어떻게 해야 할까요?

이 글에서는 야심찬 해결책을 제시합니다. 현재 상태를 점진적으로 개선하는 것(예: 이진 트리, 리프 노드 만료)과 다차원 가스와 같은 가격 책정 개선과 더불어, 기존 상태와 함께 새로운(훨씬 저렴하지만 더 제한적인) 상태 형식을 도입합니다 .

가장 큰 절충점은, 예를 들어 현재 상태 증가율을 20배로, 실행 속도를 1000배로 "목표" 수준으로 설정할 경우, 실행과 저장 간의 "상대적 가격"이 현재와 비교하여 크게 달라진다는 것입니다. 새로운 저장 슬롯을 생성하는 비용이 STARK 검증 비용보다 훨씬 더 비싸질 수도 있습니다(!!). 물론 둘 다 저렴하겠지만, 무엇이 더 저렴한지에 대한 인식은 완전히 바뀔 것입니다.

따라서 개발자는 두 가지 선택에 직면하게 됩니다. 현재와 같은 방식으로 애플리케이션을 개발한다면 비교적 낮은 거래 수수료를 감수할 수 있고, 새로운 저장 방식을 활용하도록 애플리케이션을 재설계한다면 매우 낮은 거래 수수료를 적용받을 수 있습니다. 일반적인 사용 사례(예: ERC20 잔액, NFT)의 경우 표준화된 워크플로가 제공될 것입니다. 하지만 보다 복잡한 사용 사례(예: DeFi)의 경우, 개발자는 애플리케이션별 맞춤형 구현 방식을 스스로 개발해야 할 것입니다.

현재 상태로는 10~20배 이상 확장할 수 없는 이유는 무엇일까요?

920×542 31.5KB

현재 상태 데이터는 연간 약 100GB씩 증가하고 있습니다. 이를 20배로 늘리면 연간 2TB씩 증가하게 됩니다. 4년 후에는 상태 데이터 크기가 8TB에 달하게 됩니다.

이 상태 정보는 완전 검증 노드(ZK-EVM + PeerDAS를 통해 필요한 모든 정보를 얻을 수 있으므로)에서 저장할 필요가 없으며, FOCIL 노드에서도 저장할 필요가 없습니다(VOPS는 훨씬 작아서 아무런 변경 사항이 없더라도 1TB 미만, 아마도 512GB 또는 256GB 미만일 것이며, 추가 최적화도 가능합니다). 하지만 빌더(고급 빌더뿐만 아니라 기본 소프트웨어를 실행하는 로컬 "홈 빌더" 포함)에게는 필요합니다.

8TB를 디스크에 저장하는 것 자체는 어렵지 않습니다. 상태 정보 중 일부만 "핫"하게 저장하고 나머지 부분은 데이터베이스 대신 플랫 파일에 저장하는 등 몇 가지 요령이 필요할 수 있지만, 궁극적으로 8TB 디스크는 쉽게 구할 수 있습니다. 어려운 부분은 단기 데이터 저장과 장기 데이터 저장, 이렇게 두 가지입니다.

• 숏 목표는 데이터베이스 효율성 향상입니다 . 현재 클라이언트의 데이터베이스는 수 테라바이트 규모의 상태를 처리하도록 설계되지 않았습니다. 오늘날 가장 큰 문제는 상태 쓰기 작업 시 트리에 log(n)번의 업데이트가 필요하고, 각 업데이트 작업 자체도 데이터베이스에서 log(n)번의 연산을 수행해야 한다는 점입니다. 특히 n이 RAM 용량보다 훨씬 커지면 이러한 연산량은 급격히 증가합니다. 이미 이러한 문제를 해결하는 데이터베이스 설계 방식이 존재하지만, 개선 및 광범위한 도입이 필요합니다.
• 장기적인 목표: 동기화 . 빌더가 비허가형(Permissionless) 하지 않고도 쉽게 설정할 수 있도록 하고 싶습니다. 아무리 효율적이라 하더라도 8TB를 동기화하는 데는 오랜 시간이 걸리고, 많은 경우 월별 대역폭 제한에 걸리기도 합니다.

이 모든 것은 상태를 누구로부터 동기화할 것인지 , 누가 RPC 노드를 실행할 것인지 등 수많은 문제 외에도 추가적인 고려 사항입니다. 대략적으로, 상태 크기가 두 배로 증가할 때마다 상태를 이용해 이타적으로(또는 비용을 받고) 특정 기능을 수행하려는 주체의 수는 절반으로 줄어듭니다. 데이터베이스 효율성 개선, SSD와 데이터베이스 대신 HDD와 플랫 파일 사용 이더리움 클래식(ETC) 이러한 문제 중 일부만 부분적으로 해결할 뿐, 다른 문제에는 전혀 도움이 되지 않습니다.

데이터나 연산과는 달리, 이러한 영역들은 "규모 확장을 위해 전문 건설업자에게 의존하고 있으니, 그들이 모두 사라지더라도 일반 건설업자는 10% 크기의 블록만 만들 수 있다"라고 말할 수 있는 영역이 아닙니다. 블록 하나라도 만들려면 완전한 상태 데이터가 필요합니다. 가스 사용량 제한을 줄인다고 해서 상태 데이터의 크기가 줄어드는 것은 아닙니다.

이는 (i) 계산 및 데이터보다 상태에 대해 더 보수적이어야 하고 (ii) 계산 및 데이터에 대해 작동하는 많은 "샤딩" 기술이 상태 저장에는 작동 하지 않는다는 것을 의미합니다.

강력한 무국적 정책이 불충분할 가능성이 높은 이유

이 문제를 해결하기 위해 제안된 주요 전략 중 하나는 강력한 상태 비저장(strong statelessness) 입니다. 우리는 트랜잭션을 수행하는 사용자에게 (i) 트랜잭션이 읽고 쓰는 계정 및 저장 슬롯을 지정하도록 요구하고, 지정된 범위를 벗어난 읽기 또는 쓰기 시도는 실패하도록 하는 규칙을 적용하며, (ii) 상태 접근을 증명하는 머클 분기(Merkle branch)를 제공하도록 요구합니다.

이렇게 하면 빌더가 전체 상태를 저장할 필요가 없어집니다. 대신 사용자가 직접 자신의 용도와 관련된 상태(및 업데이트된 증명)를 저장하거나, 분산 네트워크가 상태를 저장할 수 있습니다(예: 각 노드가 임의의 1/16을 유지).

581×491 25.1KB

이 접근 방식에는 세 가지 주요 단점이 있습니다.

• 오프체인 인프라 의존성 : 현실적으로 사용자는 자신에게 필요한 상태와 증명을 저장할 수 없을 것입니다. 왜냐하면 "자신에게 필요한 것"이란 무엇인지가 계속 변할 뿐 아니라, 많은 사용자가 항상 온라인 상태가 아니기 때문에 업데이트된 브랜치를 다운로드할 수 없기 때문입니다. 따라서 상태 저장 및 검색을 위한 분산형 네트워크가 필요합니다. 이는 사용자 개인정보 보호에도 영향을 미칩니다.
• 하위 호환성 문제 : 접근하는 저장소가 트랜잭션 실행에 따라 동적으로 변하는 애플리케이션은 바인딩된 접근 목록과 근본적으로 호환되지 않습니다. 여기에는 온체인 주문장, 추가 가능한 목록 및 기타 여러 유형의 구조가 포함될 수 있습니다. 이러한 애플리케이션의 경우 사용자는 로컬에서 시뮬레이션을 수행하고 접근 목록을 생성해야 하지만, 대부분의 경우 온체인에서 트랜잭션이 실패하고(가스 소모와 함께) 반복적으로 재시도해야 합니다.
• 대역폭 비용 : 각 저장 슬롯에 접근할 때마다 트랜잭션은 약 1000바이트의 증명 데이터를 제공해야 합니다. 이는 트랜잭션 크기를 크게 증가시킵니다(예: 간단한 ERC20 토큰 전송의 경우, 현재는 약 200바이트만 필요하지만, 현재는 송신자 계정, ERC20 토큰, 송신자 잔액, 수신자 잔액 각각에 대한 증명 데이터가 각각 필요하여 총 4KB가 소요될 수 있습니다).

강력한 무상태성의 약한 버전으로 " 콜드 스테이트(cold state )"라는 개념이 있습니다. 이는 특정 상태(예: 1년 이상 접근되지 않은 상태)에 비동기 지연(실제로는 1초에서 슬롯 하나 사이)을 적용하여 접근할 수 있도록 하는 것입니다. 이렇게 하면 개발자는 해당 저장 공간 없이도 실행할 수 있으며, 읽기 요청이 발생할 때마다 분산 네트워크에 데이터를 요청하면 됩니다.

이 해결책은 효과가 있을 수 있지만, 인프라 의존성이 매우 높아 취약하며, 동일한 하위 호환성 문제를 안고 있습니다. 최악의 경우, 콜드 상태의 여러 영역을 거치는 복잡한 다중 홉 의존성 그래프를 가진 트랜잭션이 발생할 수 있습니다. 예를 들어, A를 호출하고, 그 출력에 따라 다른 주소의 B를 호출하고, 그 호출의 출력에 따라 또 다른 주소의 C를 호출하는 식입니다.

상태 만료 기능을 하위 호환성을 유지하기가 매우 어려운 이유는 무엇일까요?

지난 10년 동안 상태 만료라는 개념 을 제안하려는 시도가 있어왔습니다. 이는 오랫동안 접근되지 않는 상태를 활성 상태에서 자동으로 제거하고, 해당 상태를 계속 사용하려는 사용자는 직접 "복구"해야 하는 설계 방식입니다.

이러한 설계들이 필연적으로 맞닥뜨리는 문제는 다음과 같습니다. 새로운 상태를 생성할 때, 이전에는 아무것도 없었다는 것을 어떻게 증명할 수 있을까요 ?

주소 X에 계정을 생성하는 경우, 해당 주소에 올해나 작년뿐 아니라 이더리움 역사상 모든 이전 연도에 걸쳐 그 어떤 계정도 생성되지 않았음을 증명해야 합니다.

531×261 12.7KB

매년 해당 연도의 상태 변화를 나타내기 위해 새로운 트리를 생성하는 경우("반복적인 재생성 "), N년차에 새 계정을 생성하려면 N번의 조회가 필요합니다.

이 문제를 완화하기 위해 고안된 아이디어 중 하나는 주소 기간 메커니즘입니다. 새로운 계정 생성 규칙 세트("CREATE3")를 추가하여 특정 연도(N년 이상)에만 생성 가능한 주소를 만들 수 있도록 합니다. 이러한 계정을 생성하면 N년 미만의 연도에 대한 증명을 제공할 필요가 없습니다. 왜냐하면 해당 연도에는 그러한 계정이 존재할 수 없기 때문입니다.

하지만 이 설계는 실제 이더리움 환경에 통합하려고 하면 심각한 한계에 부딪힙니다. 특히, 새로운 계정을 만들 때마다 계정 뿐만 아니라 저장 슬롯 도 생성해야 한다는 점에 주목해야 합니다. 새 계정 X를 생성하면 보유하려는 모든 토큰에 대해 X의 ERC20 잔액을 생성해야 합니다. 이는 기존 ERC20 토큰이 주소 기간 메커니즘을 제대로 이해하지 못한다는 점에서 더욱 복잡해집니다. 이더리움 프로토콜은 새로운 주소 생성 메커니즘을 통해 "2033"을 인코딩하는 주소를 가진 계정 X가 2033년 이전에 생성될 수 없다는 것을 이해할 수 있지만, X의 잔액을 저장하는 저장 슬롯은 프로토콜이 이해하지 못하는 불투명한 메커니즘인 sha256(..., X)을 사용합니다.

이 문제는 몇 가지 영리한 방법을 통해 해결할 수 있습니다 . 한 가지 아이디어는 매년 새로운 하위 계약이 생성되도록 새로운 ERC20 토큰을 설계하는 것입니다. 이 하위 계약은 해당 연도와 관련된 계정의 잔액을 저장합니다. 또 다른 아이디어는 토큰 계약이 소유할 수 있지만 계정과 함께 유지되는 새로운 유형의 저장소를 만드는 것입니다. 따라서 이 저장소도 계정과 함께 만료되거나 복원될 수 있습니다. 하지만 이 두 아이디어 모두 ERC20 토큰 계약의 로직을 완전히 재작성해야 하므로 하위 호환성이 없습니다.

상태 만료를 이전 버전과 호환되도록 만들려는 모든 시도는 비슷한 문제에 부딪히는데, 이는 모두 존재하지 않음을 증명할 마땅한 방법이 없다는 문제에서 비롯됩니다. 또한 안타깝게도 "이전에 생성되지 않은 주소/저장 슬롯"을 매핑하는 방식이 현재 방식보다 훨씬 간단하거나 규모가 작은 것은 없습니다. {32바이트 키: {0,1}} 맵은 {32바이트 키: 32바이트 값} 맵과 동일한 구현 복잡성을 지닙니다.

이러한 탐구에서 얻은 교훈

우리는 강력한 무국적 현상과 국가 소멸에 대한 탐구에서 얻은 큰 그림의 교훈을 두 가지 큰 "정형화된 사실"로 요약할 수 있습니다.

1. 모든 상태 접근을 머클 브랜치로 대체하는 것은 대역폭 측면에서 너무 많은 부담을 주지만, 예외적인 경우에만 상태 접근을 머클 브랜치로 대체하는 것은 허용 가능합니다. "상태 만료"는 바로 후자의 예입니다. 예를 들어, 상태 접근의 90%가 6개월 이내의 상태에 접근하고 10%가 그보다 오래된 상태에 접근한다고 가정하면, "빌더 필수" 상태에는 최근 상태만 유지하고 그보다 오래된 상태에 대해서는 증인을 요구할 수 있습니다. 이렇게 하면 20배의 오버헤드를 지불하는 대신 평균적으로 2배의 오버헤드(기존 트랜잭션 비용 포함)만 지불하게 됩니다.
   
   이러한 탐색은 필연적으로 계층화된 상태 , 즉 자주 접근될 것으로 예상되는 고가치 상태와 드물게 접근될 것으로 예상되는 저가치 상태를 구분하는 것이 필요하다는 결론으로 ​​이어지는 것 같습니다. 계층화는 (i) 상태 만료 제안처럼 최근성을 기준으로 하거나 (ii) 명시적으로 구분된 상태 클래스(예: VOPS는 이의 매우 제한적인 버전)를 통해 구현할 수 있습니다.
   
   
2. 하위 호환성을 유지하는 것은 매우 어렵습니다 . 하위 계층의 상태는 특정 방식(특히 동적 동기 호출)으로 조작하는 데 비용이 많이 들 뿐만 아니라, 아예 조작 자체가 불가능합니다 . 따라서 기존 애플리케이션을 완전히 망가뜨리지 않으려면, 기존 애플리케이션을 더 비용이 많이 드는 계층의 상태로 만들고 개발자가 더 저렴한 새로운 계층의 상태를 사용하도록 직접 선택하게 하는 방법밖에 없을 수 있습니다.

더 저렴한 새로운 형태의 국가를 만드는 것은 어떤 모습일까요?

기존 상태를 하위 호환성을 유지하면서 만료시킬 수 없다면, 자연스러운 해결책은 하위 호환성 부족을 받아들이고 대신 "바벨 솔루션"을 채택하는 것입니다.

• 기존 상태를 거의 그대로 유지하되, 상대적으로 더 높은 비용을 발생시키도록 합니다 (예: 실행 비용은 1000배 저렴해지지만, 새로운 상태 생성 비용은 20배만 저렴해질 수 있습니다).
• 처음부터 매우 높은 수준의 확장성을 고려하여 설계된 새로운 유형의 상태를 생성합니다 .

이러한 새로운 유형의 상태를 설계할 때, 현재 이더리움 상태의 대부분을 구성하는 객체가 무엇인지, 즉 ERC20 토큰 및 NFT와 같은 잔액이라는 현실을 염두에 두어야 합니다.

임시 보관

한 가지 아이디어는 중간 정도의 지속 시간을 가진 새로운 유형의 임시 저장소를 만드는 것입니다. 예를 들어, 새로운 기간(예: 1개월)이 시작될 때마다 초기화되는 새로운 트리 구조를 만들 수 있습니다.

이러한 유형의 스토리지는 경매, 거버넌스 투표, 게임 내 개별 이벤트, 사기 방지 검증 메커니즘 이더리움 클래식(ETC) 온체인 이벤트의 일회성 상태를 처리하는 데 이상적입니다. 가스 비용을 매우 낮게 설정할 수 있어 실행 규모에 따라 1000배까지 확장할 수 있습니다.

이러한 상태 위에 ERC20 스타일의 잔액을 구현하려면 필연적으로 다음과 같은 문제를 해결해야 합니다. 만약 누군가가 한 달 넘게 동굴에 들어간다면 어떻게 될까요?

ERC20 토큰을 사용하는 장점 중 하나는 순서에 상관없이 잔액을 복구할 수 있다는 점입니다. 예를 들어, 2025년에 100 다이(Dai) 받았는데 잊어버렸다가 2027년에 같은 계정으로 50 다이(Dai) 받았고, 나중에 이전 잔액이 생각나서 계정을 복구하면 총 150 다이(Dai) 돌려받게 됩니다. 2026년에 계정에 무슨 일이 있었는지 증명할 필요도 없습니다(만약 그때 코인을 받았다면 나중에 증명할 수 있습니다). 다만, 동일한 과거 이력을 이용해 두 번 잔액을 복구하는 것은 방지해야 합니다.

부활이 어떻게 이루어질 수 있는지에 대한 개략적인 설명은 다음과 같습니다.

• 트리 설계의 일환으로, 각 노드에 해당 노드 "아래"에 있는 리프 노드의 총 개수를 저장합니다. 이렇게 하면 어떤 리프 노드에 대한 증명 과정에서도 해당 리프 노드의 트리 내 인덱스(왼쪽에서 오른쪽 순서)를 동시에 검증할 수 있습니다. 즉, 증명 과정에서 왼쪽에 있는 모든 자매 노드의 인덱스 합계를 구하면 됩니다.
• 매달, 삭제 시점의 트리 값 하나당 한 비트(Bit) 씩, 총 네 비트로 구성된 영구 상태 비트필드를 저장합니다. 이 비트필드는 모든 비트가 0으로 초기화됩니다.
• 만약 N월에 계정 X가 슬롯 Y에 쓰기 권한을 가지고 있었다면, N 이후의 모든 달에는 해당 계정이 해당 비트필드 값을 수정할 수 있습니다. 또한, 누구나 언제든지 간단히 증명만 하면 됩니다.

961×301 9.01KB

• ERC20 계약은 기본적으로 현재 트리에 잔액을 저장하지만, 발신자의 과거 상태 항목을 증명하는 브랜치를 입력으로 받아 잔액을 부활시키는 기능을 갖습니다. 이 기능은 잔액의 비트(Bit) 0에서 1로 변경하여 다시는 부활시킬 수 없도록 합니다.

현재 이더리움의 상태 데이터는 연간 약 100GB씩 증가합니다. 만약 이더리움을 1000배로 확장한다면, 상태 데이터 증가율은 1000배로 늘어나겠지만, 이 모든 데이터는 임시 저장소에 저장될 것입니다. 이는 (한 달 만료를 가정했을 때) 약 8TB의 상태 데이터와, (상태 데이터 항목당 1 비트(Bit) , 즉 64바이트 단위이므로) 매달 8TB * 1/8 / 64 = 16GB의 영구 저장소가 필요하다는 것을 의미합니다.

UTXOs

또 다른 방법으로는 임시 저장 개념을 논리적으로 극단적으로 확장 하여 만료 기간을 0으로 설정하는 것입니다. 이렇게 하면 계약은 레코드를 생성할 수 있고, 이러한 레코드는 해당 블록 의 트리 구조로 해싱되어 즉시 기록에 저장됩니다. 각 블록 에는 레코드가 "사용됨" 또는 "사용되지 않음"을 저장하는 비트 필드가 있으며, 이는 영구적인 상태가 됩니다. 그 외에는 아무런 변화가 없습니다.

791×378 13.7KB

잠재적으로 UTXO는 기존 LOG 메커니즘을 재사용하고 그 위에 상태 비트필드 메커니즘을 추가하는 방식으로 간단하게 구축할 수 있습니다. 정말 원한다면 프로토콜 외부의 이더리움 요청 사항(ERC) 방식으로도 구현할 수 있지만, 몇 가지 단점이 있습니다. 즉, 몇몇 무작위 사용자가 다른 모든 사용자보다 256배 더 많은 비용을 지불하여 256 크기의 비트필드 섹션을 나타내는 새로운 저장 슬롯을 가장 먼저 생성해야 하는 책임을 지게 됩니다.

ERC20, NFT 및 기타 모든 종류의 상태 저장 장치를 이러한 UTXO 위에 구축할 수 있습니다.

이 두 가지 아이디어의 중간 형태인 하이브리드 버전도 있습니다. UTXO를 사용하지만, 예를 들어 최근 한 달 동안의 트리 정보를 증인 없이 상태에서 직접 접근할 수 있도록 합니다. 이렇게 하면 대역폭 부하를 줄일 수 있습니다(단, 저장 공간은 더 커집니다). 이 방식과 임시 저장소 방식의 주요 차이점은 이전에 생성된 객체(UTXO)를 처리하는 데 두 개의 인터페이스(현재 에포크 저장 슬롯과 이전 에포크 UTXO)가 아닌 하나의 인터페이스만 사용한다는 점입니다.

강력한 상태 비저장 트리

또한, 머클 브랜치를 사용하여 접근할 수 있는 단일 저장 트리를 만들 수도 있습니다(또는 대안으로, 노드는 해당 트리의 상위 N-8 레벨(즉, 크기의 1/256)을 저장해야 하며, 노드는 256바이트 크기의 증거를 제공합니다). 이 새로운 저장 트리는 기존 트리와 나란히 존재하게 되므로, 증거가 필요한 저렴한 트리와 증거가 필요 없는 비싼 트리, 이렇게 두 개의 저장 트리가 존재하게 됩니다.

하지만 제 생각에는 이 방식이 임시 저장 방식보다 열등합니다. 장기적으로 볼 때, 만약 트리의 대부분이 잊혀진 쓸모없는 데이터이고 사람들이 그중 일부에만 관심을 갖는다면, 네트워크는 최악의 경우 쓸모없는 데이터를 포함한 트리 전체를 저장해야 하거나, 최선의 경우에도 유용한 상태를 증명하는 매우 긴 머클 브랜치만 저장해야 할 것입니다 (각 유용한 상태 객체는 트리에서 쓸모없는 데이터로 "둘러싸여" 있기 때문입니다). 두 개의 트리를 사용하는 설계는 두 개의 "계층" 저장만 허용하는 반면, 임시 저장 설계는 상태 만료 메커니즘을 구축할 공간을 만들어 경제적 계층 구조 위에 최근성 계층 구조를 적용할 수 있게 합니다.

개발자 경험에 미치는 영향

다음은 이러한 계층형 아키텍처에서 애플리케이션 및 워크플로가 작동하는 방식을 보여주는 개략도입니다.

• 사용자 계정 (기본 AA와 관련된 새로운 계정별 상태 포함)은 영구 저장소에 저장됩니다. 따라서 사용자 계정은 언제든지 저렴하고 쉽게 접근할 수 있습니다.
• 스마트 계약 코드는 모두 영구 저장소에 보관됩니다.
• NFT, ERC20 토큰 잔액 이더리움 클래식(ETC) UTXO 또는 임시 저장소에 저장됩니다.
• 단기 이벤트(예: 경매, 사기 방지 게임, 오라클 게임, 거버넌스 활동)와 관련된 상태는 임시 저장소에 보관됩니다.
• 핵심 DeFi 계약은 구성 가능성을 극대화하기 위해 영구 저장소에 보관됩니다.
• 개별적인 디파이 활동 단위 (예: CDP)는 많은 경우 UTXO 또는 임시 저장소에 보관됩니다.

초기에는 개발자들이 모든 것을 기존의 영구 저장소에 계속 저장할 수 있을 것입니다. 아마도 NFT와 ERC20 토큰 잔액이 UTXO나 임시 저장소로 옮기기 가장 쉬울 것입니다. 그 후 생태계는 시간이 지남에 따라 더욱 효율적인 저장소 사용을 위해 최적화될 것입니다.

여기서 핵심 가설은 "UTXO만 사용하는 방식"보다 "영구 저장소와 UTXO를 혼합하여 사용하는 방식"이 개발하기 훨씬 쉽다는 것입니다. 이더리움이 개발자 플랫폼으로서 큰 성공을 거둔 주요 이유 중 하나는 계정과 저장소 슬롯이 UTXO보다 훨씬 개발자 친화적이기 때문입니다. 예를 들어, 상태 정보의 95%를 큰 어려움 없이 UTXO로 옮기고 나머지 5%는 영구 저장소로 유지할 수 있도록 개발자 친화적인 추상화 계층을 제공하고, (영구 저장소 사용조차 어려워하는 개발자에게는 더 높은 비용을 감수하고 모든 것을 영구 저장소에 저장할 수 있는 옵션을 제공하는 방식도 고려한다면) UTXO의 확장성 이점과 이더리움식 계정 및 저장소 슬롯의 개발자 친화성 이점을 동시에 얻을 수 있을 것입니다.