모든 주가 평등한 것은 아니다

이더리움의 상태는 고르지 않습니다. 소수의 컨트랙트가 대부분의 저장 공간을 차지하는 반면, 대부분의 계정은 단기간(때로는 단 하나의 블록만)만 유지됩니다. 상태 접근 패턴을 연구하면 무엇이 핫(Hot) 상태로 유지되고 무엇이 콜드(Cold) 상태로 유지되는지 알 수 있습니다. 실제 사용 환경에 최적화하면 실행 계층의 속도를 높일 수 있습니다.

분석

본 연구는 계정 유형, 바이트코드 사용, 배포자 및 팩토리 패턴, 코드 크기, 슬롯 활동별 상태 사용량을 분석합니다. 제네시스 부터 펙트라 이전 블록 22,431,083 (2025년 5월)까지의 모든 블록을 포괄합니다.

EOA 대 계약 - 어느 쪽이 더 오래 유지될까?

활동 범위 = 특정 상태에 대한 첫 번째 액세스부터 마지막 액세스(읽기 및 쓰기)까지의 블록 거리입니다.
0 활동 범위 = 상태가 단일 블록에서만 액세스되었습니다.

1블록 = 12초라고 가정합니다.

S1afkFMcxx.png 1189×790 32.6KB

rJvp0Ofqxx.png 1189×790 33.7KB

1. EOA는 확실히 계약보다 오래 지속됩니다.
   EOA는 0이 아닌 중간값 기간(약 3.1일)을 가지지만, 중간값 계약 기간은 0 입니다. EOA의 오른쪽 꼬리는 모든 분위수(q75, q95)에서 더 굵어지며, 이는 더 큰 장수 코호트를 나타냅니다.

2. 대부분의 계약은 설계나 의도상 일시적입니다.
   계약의 약 55%가 제로 스팬 계약입니다. 다음과 같은 요인이 있을 수 있습니다.

   • 공장 스팸 및 대량 주조 템플릿 (예: 토큰 복제, 후속 조치가 전혀 없는 쌍 계약).
   • 단일 거래를 위해 생성된 MEV/유틸리티 배포 .
   • 자체 파괴 패턴 (특히 EIP-6780 이전)은 생성과 파괴가 동일한 블록/거래 내에서 발생하는 패턴입니다.

3. "단기 EOA"도 흔합니다.
   EOA 중간값은 첫 번째 관찰에서 마지막 관찰까지 약 3.1일 동안만 활성화되며, 75%는 약 6개월 이내에 종료됩니다. 여기에는 일회성 청구자/채굴자, 거래소 입금 주소, 봇 지갑이 포함될 수 있습니다.

4. 장기 계약도 존재하지만, 일반적이지 않습니다.
   다년 계약은 토큰 계약(ERC-20/721), 레지스트리, 라우터, 멀티시그/프록시 관리 계약 및 기타 핵심 요소와 같이 표준 기반 또는 인프라 기반 계약인 경우가 많습니다. 많은 애플리케이션 팀이 업그레이드 시 주소를 순환 사용하는데, 이로 인해 새로운 배포 환경에서의 활동이 분산되고 각 주소의 측정 기간이 단축됩니다.

계약은 얼마나 다양합니까?

1개의 계약 ≠ 1개의 고유한 애플리케이션. 실제로 많은 계약이 기존 바이트코드를 재사용하거나 동일한 템플릿(팩토리 포함)을 사용하여 배포됩니다. 다음과 같은 다양한 범주를 기준으로 계약을 분석할 수 있습니다.

• 템플릿 대 고유 바이트코드
• 배포자 주소별
• 공장 주소별
• 코드 크기별
• 상태 저장(슬롯 있음) vs. 상태 비저장(슬롯 없음)

템플릿 대 고유 바이트코드

템플릿 = 두 개 이상의 계약 주소에 의해 배포된 바이트코드 해시입니다.
고유성 = 바이트코드 해시가 정확히 한 번 배포됨.

SJdamI49lg.png 1189×790 69.6KB

데이터가 보여주는 것:

• 계약 집중도 심화 : 약 15만 개의 템플릿 바이트코드가 전체 계약의 97%를 차지합니다. 상위 1개 코드 해시만으로 계약의 14.4%를 차지하고, 상위 10개 는 51% , 상위 100개 는 81.8%를 차지합니다. 이는 구현의 다양성보다는 롱테일 템플릿 재사용이 심화되고 있음을 보여줍니다.
• 슬롯은 복제본이 있는 곳이 아닙니다 . 계약의 2.9% 에 불과하지만 고유 바이트코드는 템플릿의 경우 약 4억 2,910만 개에 비해 약 8억 7,520만 개의 저장 슬롯을 보유합니다. 상태의 약 67%가 일회성 구현에 있습니다.

고유 계약의 중간 활동 기간(약 4.1개월)은 템플릿(약 2.1개월)의 거의 두 배에 달합니다. 이는 직관과 일치합니다. 많은 템플릿이 최소한의 프록시/클론, 토큰 팩토리 또는 일시적인 배포(스팸/밈코인, MEV 스캐폴딩, EIP-6780 이전 자체 파괴 패턴)로, 수명이 짧거나 생성 이후에는 사용되지 않습니다.

고유 컨트랙트가 상태 기반이 더 많다는 것은 더 크고 지속적인 데이터를 관리하는 복잡한 시스템(DEX, 스테이킹, 브리지, 롤업 인프라)을 반영하는 것일 가능성이 높습니다. 반대로, 컨트랙트에서 템플릿 비중이 높다는 것은 활동 기간이 짧은 배포가 긴 이유를 설명하며, 많은 클론이 생성 후 의미 있는 실행을 하지 못하는 경우가 많습니다.

배포자 주소별

단일 = 단 하나의 계약만 배포하는 배포자입니다.
Multiple = 두 개 이상의 계약을 배포하는 배포자입니다.

BkDlFuNqle.png 1190×790 37KB

rJneK_Vcxl.png 1189×790 72.8KB

데이터가 보여주는 것:

• 소규모 집단이 거의 모든 배포를 담당합니다 . 배포자 중 15.1% 만이 계약의 90.4%를 차지합니다. 집중도는 극심합니다. 상위 500개 배포자만 전체 계약의 57.4%를 담당하고, 가장 큰 배포자 한 명이 전체 계약의 3.15%를 차지합니다.
• 활성 배포자는 평균적으로 더 오래 지속되고 슬롯이 더 많은 계약을 생성합니다 . "다중" 배포자의 계약은 약 3.5배 더 오래 지속되고(687,000 블록 vs 197,000 블록), 계약당 약 6배 더 많은 슬롯을 사용합니다(193개 vs 31개 슬롯). 이 패턴은 일회성 실험보다는 온체인에서 제품을 유지 관리하는(그리고 성공적인) 팀/서비스에 적합합니다.
• 하지만 최상위 볼륨 배포자는 일시적입니다 . 볼륨 기준 상위 10개 업체 중 계약은 활동 기간이 매우 짧고(평균 수백 블록) 저장 공간도 매우 부족합니다. 이는 대량 생산된 클론, 공장 스팸, MEV 스캐폴딩과 일맥상통합니다. 다시 말해, "다중" 그룹 내에서는 빌더 (내구성 있고 상태 저장형 배포)와 스프레이어 (대량, 단기 배포)로 구분됩니다.

계약 배포는 매우 집중되어 있습니다. 대부분의 장기적이고 국가 중심적인 계약은 반복 배포자로부터 발생하는 반면, 가장 많은 배포자가 단기 배포자로 체인을 가득 채웁니다.

여러 계약을 배포하는 경우, 실수를 해서 계약을 다시 배포해야 했을 수도 있습니다.

공장 주소별

비공장 = EOA에서 직접 생성(중개 계약 없음).
공장 - 개인 = 정확히 한 명의 자녀를 낳은 계약에 의해 만들어졌습니다.
공장 - 다중 = 한 명 이상의 아이를 낳은 계약에 의해 만들어졌습니다.

SySRZ8V5gl.png 1189×790 37.8KB

SJefMUNqex.png 1189×790 65.4KB

데이터가 보여주는 것:

• 대부분의 계약은 팩토리에서 생성된 복제본입니다. 전체 계약의 약 89.1%는 다중 계약 팩토리 (32,929개 주소)에서 생성되는 반면, 팩토리 없이 배포되는 계약 은 10.9% 에 불과합니다. 그러나 팩토리가 아닌 계약은 평균적으로 팩토리 자식(팩토리 자식 계약당 약 178~197개 슬롯, 블록당 약 431 ~510,000개 )보다 더 크고 (계약당 약 313개 저장 슬롯) 더 오래 활성화됩니다 (중간 활동 기간 약 769,000 개 블록).
• 집중도가 매우 높습니다. 상위 5개 공장이 전체 배포의 약 43%를 차지하고 상위 100개 공장이 약 89%를 차지합니다. 공장의 절반은 5개 이하의 계약을 배포하고, 99%는 4,978개 이하 의 계약을 배포합니다.

팩토리는 저렴하고 가벼운 코드를 확장합니다. 개별 및 다중 팩토리 그룹에서 계약당 슬롯 수가 적고 활동 기간이 짧은 것은 프록시 패턴, 토큰/페어 스팸, 에어드랍 채굴, MEV/스캐폴딩 계약과 일맥상통합니다. 대량 생산이 쉽고 수명이 짧은 경우가 많으며, 많은 경우 의미 있는 슬롯을 확보하지 못합니다.

비공장 배포는 인프라에 치우쳐 있습니다. 더 많은 스토리지와 더 긴 기간은 EOA/멀티시그가 직접 배포하고 시간이 지남에 따라 활성 상태를 유지하는 맞춤형 시스템(거버넌스, 볼트, 라우터, 브리지, 롤업 인프라)을 시사합니다.

"개별 팩토리" ≠ 지속형. 자식 노드를 하나만 생성하는 팩토리는 비팩토리 배포보다 배포 기간이 짧고 슬롯 수도 적습니다. 많은 팩토리가 장기 실행 애플리케이션이라기보다는 부트스트랩이나 허영적인 팩토리 사용처럼 보입니다.

코드 크기별

Age = 최신 블록(22431083) - 상태가 처음 나타난 블록입니다.

Hkeyz_Bcle.png 1389×989 46.9KB

HJN1z_Sqxx.png 1390×790 34KB

데이터가 보여주는 것:

• Tiny가 압도적이지만, 두 세계는 완전히 다릅니다 . Tiny 계약은 전체 계약의 약 88%를 차지하지만, 절반 이상 (57.9%)이 제로 스팬(zero-span) 이며, 이는 대량 생성된 클론과 스텁과 일치합니다. 그러나 활동이 있는 계약들 중에서 Tiny는 모든 그룹 중 가장 긴 중간 스팬 ( 약 219만 블록, 약 10개월 )을 보이며, 이는 장기 사용의 또 다른 하위 집단임을 보여줍니다.
• 활동 기간 대 규모는 단조롭지 않고 U자형입니다 . 0이 아닌 활동 기간을 가정하면, 중간 규모 기간은 작음 → 작음 → 중간 → 큼 ( 가장 짧음, 약 8.3k 블록 약 1일 )으로 감소한 후 매우 큼(약 273k 블록 약 1개월) 으로 반등합니다. 따라서 중간 규모의 코드가 가장 빠르게 이탈하기 때문에 "큰 코드가 더 오래 작동한다"는 주장은 거짓입니다.
• 모든 규모 범주에는 장수명 꼬리가 있습니다 . P99는 모든 규모에 걸쳐 약 1,000만~1,170만 블록(약 3~4년)의 클러스터를 형성합니다. 즉, 모든 버킷의 계약 중 소수만이 수년간 유지됩니다.

소규모 계약은 일반적으로 프록시와 공장 복제본으로 구성됩니다. 대부분은 저렴하고 일회용이며 전혀 사용되지 않습니다. 그러나 중요하고 실제로 유용한 계약은 훨씬 더 오랫동안 작동하기 때문에 0이 아닌 코호트 간의 긴 지속 기간이 있습니다. 또 다른 가능성은 업그레이드에 사용되는 게이트웨이 계약일 수 있습니다.

소규모/중규모/대규모 계약은 맞춤형 하이프 사이클 계약(토큰/NFT 채굴/팜, 일회성 앱 로직)에 집중되어 있습니다. 또한 팀은 업그레이드 시 주소를 순환하여 활동 범위를 분산시킵니다.

매우 큰 규모의 계약은 종종 복잡한 시스템을 시사합니다. 중간 규모의 계약보다 드물고 수명이 길지만, 성공률이 균일하지는 않습니다. 일부 대규모 배포는 도입되지 않기도 합니다.

상태 저장 계약과 상태 비저장 계약

Stateful = 최소 1개의 저장 슬롯이 있는 계약
무국적 = 저장 슬롯이 0개인 계약

SkEvo3Sqll.png 1189×790 27.2KB

데이터가 보여주는 것:

• 대부분의 계약은 무국적 계약입니다. 53.9%는 스토리지에 전혀 손을 대지 않고, 46.1%는 손을 대고 있습니다.
• 무활동은 무상태 계약에서 더 일반적입니다. 무 상태 계약의 경우 58.9%, 유상태 계약의 경우 50.8%입니다.
• 상태 비저장 계약은 더 오래 작동합니다. 0이 아닌 기간의 중간값은 상태 저장 계약보다 약 30배 더 깁니다(1.2년 대 14.6일).

이런 일이 일어날 가능성이 있는 이유

• Stateless = 저렴하고 내구성 있는 유틸리티. 대부분은 간단한 포워더, 프록시 또는 헬퍼입니다. 대량으로 배포하기 쉬워서 결국 스팬이 0이 되는 경우가 많지만, 유용한 유틸리티는 데이터를 보관하지 않고 마이그레이션이 필요 없기 때문에 수년간 실행할 수 있습니다.
• 상태 저장 = 업그레이드 또는 교체. 데이터를 저장하는 토큰, 풀, 볼트 및 앱은 최신 버전으로 업그레이드되거나 교체될 가능성이 더 높습니다. 이를 통해 새 주소로 활동이 분산되고 각 이전 주소의 지속 시간이 단축됩니다.

저장 슬롯은 얼마나 활발하게 사용되고 있나요?

rypm9YS5gl.png 1389×989 44.8KB

r1FsHjB5le.png 1189×790 71.4KB

데이터가 보여주는 것:

• 저장 슬롯의 절반 이상(63.3%)이 임시 저장 슬롯입니다 . 이러한 슬롯은 설정 후 절대 접근할 수 없습니다.
• 집중도가 매우 높습니다 . 단일 계약이 전체 슬롯의 약 6%를 차지합니다( XEN Crypto 참조). 상위 1,000개 계약이 전체 슬롯의 약 51%를 차지합니다.

0 활동 슬롯은 일회성 플래그, 에어드롭 청구, 초기화 기록, 포기된 잔액 또는 빠르게 교체된 계약의 데이터에 일반적으로 사용됩니다.

소수의 대규모 시스템이 이더리움의 라이브 스토리지 슬롯 대부분을 담당합니다. 그렇기 때문에 극히 일부의 계약이 전체 슬롯을 차지하는 것입니다.

한 가지 주의할 점은 프록시 패턴이 일반적으로 로직과 스토리지를 분리한다는 것입니다. 로직 계약은 종종 상태가 없고 오래 지속되는 반면, 스토리지 계약은 상태를 유지하고 순환될 수 있습니다. 주소만 살펴보면(프로젝트가 아님) 상태가 있는 프록시의 스팬이 더 짧다는 것을 알 수 있습니다.

"활동 없음"으로 표시된 일부 슬롯은 RPC 호출을 통해 오프체인에서 읽힐 수 있습니다. 이러한 읽기는 온체인에 나타나지 않습니다.

오픈 아이디어

상태 만료

대부분의 상태는 빠르게 냉각됩니다. 실용적인 방향은 부활 계획을 통해 비활성 상태를 주기적으로 정리하는 것 입니다.

• 창 : 12~18개월 활동 창이 분포에 적합합니다. 많은 주 토지의 중간 비0 기간은 1년도 채 되지 않지만, 장수한 주는 그보다 깁니다.
• 이점 : 핫 상태를 작게 유지하고, 상태 성장을 늦추고, 디스크 I/O를 줄이고, 스토리지 크기를 줄이고, 블록 처리 시간을 개선합니다.

우선, 활동 기간이 0인 계정과 저장 슬롯을 제거 하면 얼마나 많은 저장 공간을 절약할 수 있는지 생각해 보겠습니다. Geth의 플랫 스냅샷(키-값 "상태" 테이블)에서 이를 측정하여, 해당 키가 제거된 스냅샷(노드가 블록 22,431,083에 동기화됨)과 원본 스냅샷을 비교했습니다.

스냅샷에서만 제로 스팬 상태를 제거하면 저장 공간이 약 56% 줄어 듭니다. 이는 상태 만료로 인해 핫 상태 세트가 실질적으로 줄어들 수 있다는 강력한 신호입니다.

이미 존재하는 바이트코드에 대한 더 저렴한 배포

클라이언트가 일반적으로 코드 해시를 통해 디스크에서 바이트코드 중복을 제거하더라도, 중복된 코드는 배포 시 가스를 낭비합니다. 몇 가지 실행 가능한 변형은 다음과 같습니다.

1. 로컬 중복 할인(동일한 블록/에포크) : 바이트코드 codehash 동일한 블록 (또는 짧은 에포크)에 두 번 나타나는 경우 두 번째 배포에서는 감소된 코드 보증금을 지불합니다.
   • 장점
     • 계약 배포 순서에 따라 블록에서 쉽게 검증 가능
     • 공장 및 AA 지갑의 가스 비용 즉각 절감
     • 할인은 블록 내에서만 적용되므로 스팸 영향을 제한합니다.
   • 단점
     • 불공정성: 누가 전체 금액을 지불해야 합니까?
     • EL 클라이언트 구현의 복잡성
2. 글로벌 "코드해시 레지스트리" : codehash → exists . 모든 계약 배포는 먼저 바이트코드가 이미 존재하는지 확인합니다.
   • 장점 :
     • AA 지갑, 프록시 및 공장 계약에 대한 가스 비용 절감.
     • 바이트코드가 이미 존재하는 경우 계약에 위임하는 가능한 메커니즘
   • 단점 :
     • 스팸 복제본에 인센티브를 제공합니다.
     • 레지스트리에 DoS 표면을 추가합니다. 스팸 발송자가 할인을 남용하지 않도록 신중한 가격 책정이 필요합니다.
     • 저장 트라이 크기가 커짐에 따라 바이트코드 해시는 상태 증가에 문제가 될 수 있습니다.
     • ZKEVM은 코드 해시의 존재를 증명해야 합니다.
3. 라이브러리당 단일 계약 : 동일한 라이브러리에 대해 중복된 코드를 생성하는 대신, 코드 해시만 사용되는 "라이브러리 계약"을 배포하는 새로운 opcode LIBCREATE 추가합니다. 이는 라이브러리 중복 제거에 유용할 수 있지만, 추가 분석 결과 해당 라이브러리가 실제로 계약에서 상당한 비중을 차지하고 있는 것으로 확인되는 경우에만 해당됩니다.

주소당 점진적 스토리지 가격 책정

오늘날 소수의 계약이 글로벌 저장 시장을 장악하고 있습니다. 우리는 한계 부담을 반영하는 가격을 원할지도 모릅니다.

점진적 주소별 스토리지 가격 책정 : 기본 SSTORE 비용에 slot_count(address) 가 임계값을 초과할 때 단계별 추가 요금 이 부과됩니다(EIP-2027 스타일 메타데이터처럼 프로토콜 내 슬롯 카운터 필요). 비용을 예측 가능하게 유지하면서도(단계별), 대규모 계약의 경우 상태 외부화 비용을 내부화하도록 유도합니다.

장점:

• 주소의 실제 저장 용량 증가에 따른 비용을 연결합니다.
• 계층형 요금제는 슬롯별 요금 재조정보다 비용을 계획하기 쉽습니다.
• "무제한 슬롯"이 남용되지 않도록 더 나은 스토리지 설계를 장려합니다.

단점:

• 슬롯 수 메타데이터와 규칙이 필요합니다. 복잡성이 증가합니다.
• tx가 tier mid-tx를 교차할 때 가스 추정이 더 어렵습니다.
• 개발자가 여러 계약에 걸쳐 상태를 분할하도록 만들 수 있습니다(호출이 더 많아지고, 표면이 더 넓어지고, UX가 나빠짐).
• 유용한 계약에는 많은 슬롯이 있는 경향이 있으며, 우리는 이를 활성화하는 데 대해 처벌하고 있습니다.

임시 저장 모델

많은 슬롯이 한 번 작성되고 다시는 건드리지 않습니다. 개발자에게 단기적으로 유지되는 데이터를 결정적으로 삭제할 수 있는 저렴하고 계약적으로 읽을 수 있는 공간을 제공하세요.

작동 원리(상위 수준):

• 계정별 임시 저장소 루트 : 임시 데이터를 위해 각 계약 계정에 tempStorageRoot 추가합니다.
• 글로벌 기간 버킷 : 모든 쓰기는 현재 기간(예: 6-12개월)으로 이동합니다.
• 결정적 만료 : 기간이 끝나면 EL 클라이언트가 물리적으로 정리했는지 여부에 관계없이 해당 데이터는 읽기에 대해 논리적으로 0이 됩니다.
• 가격 책정 : 현재 SSTORE 더 비싸게 만들고 임시 저장소에 데이터를 저장하는 비용을 SSTORE 보다 저렴하게 만듭니다.

장점:

• 의도된 수명에 맞게 비용을 조정합니다.
• 간단한 정신 모델: "N개월 후에 손실해도 괜찮은 데이터는 임시 저장소에 보관하세요"
• 미래 상태 만료 작업과 직교(및 호환)

단점:

• 새 계정 필드로 인해 계정 마이그레이션이 필요합니다.
• 개발자가 저장소 재설정 이후의 값에 의존하는 경우 툴링 위험
• 남용을 방지하기 위해 가스 일정을 신중하게 조정해야 합니다.
• 배치된 계약의 SSTORE 는 가스 비용이 더 높고 불공평할 수 있습니다.

EL 클라이언트의 성능 개선

EL 클라이언트가 이러한 정보를 활용하여 성과를 개선할 수 있는 방법에 대한 몇 가지 아이디어:

• 저장 엔진에서 핫/콜드 상태 분리 : 최근에 터치한 계정/슬롯을 "핫" 저장 엔진에 보관한 다음, 콜드 상태의 계정/슬롯은 일괄 압축하고 스냅샷을 덜 자주 생성하여 쓰기 증폭을 줄입니다.
• 슬롯 수 기반 커밋 : 슬롯 점유율이 큰 대형 계약의 트라이 경로에 대한 데이터베이스 커밋을 우선적으로 처리합니다. 이를 통해 가장 심각한 위반 사항을 먼저 처리합니다.
• 자주 보이는 코드 해시를 캐시하고 존재 여부를 확인합니다 . 계약 생성 시 중복 바이트코드를 다시 유지하는 것을 건너뛰어 쓰기 증폭과 압축 압력을 줄입니다.

폐쇄

이더리움의 문제는 단순히 상태 증가만이 아닙니다. 오래된 상태를 처리할 방법이 없습니다.

대부분의 계정은 수명이 짧습니다. 팩토리와 템플릿 클론이 배포를 주도하지만, 고유 컨트랙트가 대부분의 저장 공간을 차지합니다. 소수의 컨트랙트가 대부분의 슬롯을 차지하며, 많은 슬롯은 한 번 작성되고 다시는 건드리지 않습니다. 이러한 문제를 해결하면서 구성 가능성을 해치지 않는 돌파구를 찾을 수 있다면, 이더리움은 더 빠르게 확장될 수 있습니다.

모든 상태가 동일한 것은 아닙니다. 아마도 프로토콜이 모든 상태를 동일한 것처럼 취급해서는 안 될 것입니다.

감사의 말

놀라운 Xatu 인프라를 제공해 준 ethPandaOps 팀에 특별히 감사드립니다.

또한 이 기사를 검토해 주신 Guillaume, Carlos, Matan, Ignacio에게도 감사드립니다.

다음 단계

• 강도 분석 : 활동 강도와 함께 쌍을 이루어 "조용하고 오래 지속되는" 상태와 "짧지만 강렬한" 상태를 구분합니다. 소모된 가스량도 고려해야 합니다.
• 라벨별 그룹화 : 추론을 더욱 확고히 하기 위해 라벨(예: 토큰, 라우터, 볼트, 브리지, 팩토리, 프록시)을 사용하여 분석합니다.
• EIP-6780 이후 자체 파괴 : EIP6780으로 인해 자체 파괴되어 상태 트리에서 제거될 예정이었던 계약이 몇 개나 되는지 조사해 보세요. 또한 SENDALL 명령어를 실행한 계약도 몇 개나 조사해 보세요.
• 빈 잔액 계약 : 몇 년 동안 HODL(보유) 상태로 있다가 빈 잔액으로 남는 계약이 몇 개나 되는지 확인하세요. 사용하지 않을 계약이라면 삭제해도 아무도 신경 쓰지 않을 겁니다.
• 라이브러리 : 라이브러리를 사용하여 얼마나 많은 계약이 배포되는지 확인하세요.
• 고유/템플릿 구분에 따른 공장/비공장 계약 분포.
• 다양한 속성(예: 배포자, 팩토리, 코드 해시, 카테고리)과 EL 클라이언트에서 해당 속성이 차지하는 저장 공간의 크기를 기준으로 클러스터를 식별합니다.

충수

분석 코드 저장소에 대한 링크입니다 .