신규 스마트계약 수가 생태계 성장과 다른 이유

신규 계약 수는 새 계약 주소가 생긴 규모를 보여 주지만 독립 앱이나 개발팀의 수를 뜻하지 않습니다. 팩토리가 동일한 기능의 계약을 대량 생성하거나 하나의 앱이 여러 프록시와 구현 계약을 사용할 수 있기 때문입니다. 배포 건수와 함께 고유 코드 계열, 배포 주체, 소스 검증, 후속 이용을 나누어 보아야 합니다.

새 주소가 천 개 생겨도 새 앱 천 개는 아닐 수 있습니다

서비스가 사용자별 금고를 만들거나 거래쌍마다 풀을 배포하면 하나의 제품에서 많은 계약 주소가 생길 수 있습니다. 반대로 여러 기능을 한 계약에 담는 구조에서는 적은 주소로 복잡한 서비스를 운영할 수 있습니다. 계약 수는 구조 선택의 영향을 크게 받습니다.

가상 서비스가 고객 1,000명을 위해 각각 별도 금고를 만들었다고 가정합니다. 새 계약 주소는 1,000개지만 서비스를 만든 앱은 하나이고 공통 구현 코드도 하나일 수 있습니다. 그 수치를 ‘독립 프로젝트 1,000개 출범’으로 바꾸어 쓰면 관측한 것보다 훨씬 큰 주장을 하게 됩니다.

새 주소가 나타난 원인을 분류하면 성장 해석이 달라집니다. 이용자별 상태를 분리한 배포인지, 새로운 기능을 가진 제품인지, 업그레이드 준비나 시험용 배포인지 확인해야 합니다. 분류가 안 된 계약은 미분류로 남기는 것이 임의로 활성 앱에 포함하는 것보다 정확합니다.

계약 주소의 증가는 배포 구조의 변화일 수 있으며, 독립적인 제품의 증가를 바로 뜻하지 않습니다.

JOBCOIN 개발 지표 해설

VISUAL GUIDE온체인 기록을 해석하는 순서

1. 01
   새 주소가 천 개 생겨도 새 앱 천 개는 아닐 수 있습니다

   서비스가 사용자별 금고를 만들거나 거래쌍마다 풀을 배포하면 하나의 제품에서 많은 계약 주소가 생길 수 있습니다.

2. 02
   팩토리와 복제 계약은 기능을 반복 배치하는 구조입니다

   ERC-1167은 알려진 고정 구현 주소로 호출을 전달하는 작은 프록시 바이트코드를 정의합니다.

3. 03
   프록시와 구현 주소를 앱 단위로 묶어 읽습니다

   업그레이드 가능한 앱은 이용자가 접하는 프록시 주소와 실행 로직을 제공하는 구현 주소가 나뉠 수 있습니다.

AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

팩토리와 복제 계약은 기능을 반복 배치하는 구조입니다

ERC-1167은 알려진 고정 구현 주소로 호출을 전달하는 작은 프록시 바이트코드를 정의합니다. 동일 기능을 적은 배포 비용으로 여러 주소에 제공하려는 목적의 표준입니다. 이런 계약을 개수만으로 세면 공통 기능을 반복 배치한 정도가 크게 반영될 수 있습니다.

팩토리는 다른 계약을 생성하는 계약입니다. 많은 생성 거래가 한 팩토리를 거쳤다면 배포 주소가 많아도 실제 구현 계열은 적을 수 있습니다. 다만 같은 팩토리를 사용했다고 모든 이용자가 같은 조직 소속인 것은 아닙니다. 공개 도구를 여러 팀이 사용할 수 있기 때문입니다.

복제 여부를 판단할 때는 배포된 코드와 전달 대상, 초기 설정을 함께 봅니다. 코드가 비슷해도 관리자나 매개변수, 연결 자산이 달라 위험과 목적이 다를 수 있습니다. ‘같은 코드 계열’은 분석상 묶음이지 모든 계약이 동일하게 동작한다는 보증이 아닙니다.

프록시와 구현 주소를 앱 단위로 묶어 읽습니다

업그레이드 가능한 앱은 이용자가 접하는 프록시 주소와 실행 로직을 제공하는 구현 주소가 나뉠 수 있습니다. 구현을 새로 배포하고 연결만 바꾸면 계약 생성 수는 늘어도 독립 앱이 하나 더 생긴 것은 아닐 수 있습니다. 프록시 계약과 구현 계약의 관계를 알아야 이러한 변화가 보입니다.

OpenZeppelin의 프록시 문서는 여러 패턴과 복제 도구를 구분합니다. 따라서 모든 프록시를 업그레이드 가능한 동일 구조로 취급하지 않습니다. ERC-1167의 고정 전달 대상 구조와 관리자 권한으로 구현을 바꾸는 구조는 집계에서 별도 속성으로 두는 편이 설명하기 쉽습니다.

주소를 제품 단위로 묶을 때는 온체인 관계와 프로젝트가 공개한 배포 목록을 대조합니다. 이름이 비슷하거나 같은 날 만들어졌다는 이유만으로 합치지 않습니다. 불확실한 연결은 추정이라고 표시하고 나중에 근거가 추가되면 재분류할 수 있도록 관측 원본을 보관합니다.

소스 검증 표시가 알려 주는 범위를 제한합니다

ethereum.org는 소스 코드 검증을 제공된 고수준 코드가 해당 배포 바이트코드와 대응하는지 확인하는 과정으로 설명합니다. 이는 코드가 어떤 일을 하는지 검토할 기반을 제공하지만 취약점이 없다는 결론과는 다릅니다. 형식 검증이나 보안 감사와도 같은 절차가 아닙니다.

분석 표에서 검증된 계약 비중을 제시할 때는 분모가 전체 배포인지, 고유 구현인지, 프록시를 포함하는지 적습니다. 하나의 검증된 구현을 공유하는 많은 프록시를 어떻게 처리하느냐에 따라 비율이 달라집니다. 탐색기마다 표시 범위가 다를 가능성도 확인합니다.

공개된 코드가 있다고 해서 실사용, 운영 지속성, 경제적 성과가 확인된 것은 아닙니다. 감사 조치 보고서가 있더라도 그 보고서의 코드 버전과 배포 버전이 일치하는지 별도로 보아야 합니다. 검증이라는 한 단어에 여러 검토 결과를 모두 넣지 않는 것이 핵심입니다.

배포 후 관측 창을 두고 실제 사용을 확인합니다

당일 신규 계약을 조사할 때는 아직 사용될 시간이 충분하지 않을 수 있습니다. 배포 후 7일 또는 30일 같은 관측 창을 정하고 그 기간에 성공한 호출, 고유 호출 주소, 기능별 동작이 있었는지 봅니다. 어떤 기간이 적절한지는 서비스의 사용 주기와 질문에 따라 달라집니다.

활동이 보인다고 곧바로 실제 고객 이용으로 확정하지는 않습니다. 배포자 자신의 초기화나 점검, 자동화 실행이 대부분일 수도 있습니다. 외부 호출자와 배포 주체의 관계를 추정할 때도 주소 소유권을 확정한 것처럼 표현하지 않습니다.

신규 주소의 재방문 분석과 연결하면 처음 배포된 계약이 이후에도 쓰이는지 집단별로 비교할 수 있습니다. 이때 최근 계약처럼 후속 창이 끝나지 않은 항목은 아직 관측 중이라고 표시합니다. 오래된 계약만 남겨 분석하면 실패하거나 방치된 배포가 사라지는 편향이 생길 수 있습니다.

• 최상위 생성과 팩토리 내부 생성을 수집하는 범위를 확인합니다.
• 복제 계열과 프록시·구현 관계를 분류합니다.
• 배포자 주소를 실제 팀 수로 치환하지 않습니다.
• 소스 검증과 감사 상태를 별도 열에 둡니다.
• 동일한 후속 기간의 성공 호출과 반복 사용을 비교합니다.

생태계 성장이라는 결론에는 추가 근거가 필요합니다

개발 활동의 폭을 설명하려면 계약 수뿐 아니라 새로운 기능, 유지보수, 실제 사용의 지속성을 보아야 합니다. 기존 제품이 많은 사용자별 인스턴스를 만든 것은 사용 확대의 한 단서가 될 수 있지만 새 개발팀의 유입과는 다른 현상입니다. 두 가지를 구분해서 쓰면 각각의 의미를 더 정확히 전달할 수 있습니다.

보고서에는 원시 배포 수와 분류 후 코드 계열, 후속 활동 계약 수를 함께 제시합니다. 제외한 시험 계약의 기준과 확인되지 않은 부분도 남깁니다. ‘배포가 늘었다’는 관측에서 ‘경쟁력 있는 서비스가 늘었다’는 평가로 넘어갈 때 어떤 추가 자료를 사용했는지 독자가 따라갈 수 있어야 합니다.

자주 묻는 질문