계정 온보딩을 위한 네트워크 RAM 기금

요약

네트워크 소유 계정(ram.vaulta)은 기존 네트워크 RAM 보유분에서 조달한 RAM 기금을 보유하며, 승인된 생성자가 신규 생성 계정에 RAM을 기증할 수 있도록 합니다. 생성자는 무료 또는 유료로 신규 사용자를 온보딩하면서 RAM 비용을 직접 부담하지 않으며, 네트워크 RAM을 판매하는 대신 사용함으로써 생성자의 지속 가능한 운영을 지원합니다. 기증된 RAM은 RAM 시장에서 영구적으로 격리됩니다. 수령자는 이를 판매하거나 전송할 수 없으며, 유일한 반환 경로는 기증 계정으로의 회수뿐입니다. 본 제안은 시스템의 생성만을 다룹니다. 등록된 생성자가 없는 상태로 출범하며, 각 생성자는 이후 별도의 15/21 BP MSIG를 통해 개별적으로 승인됩니다.

근거

• 온보딩: 계정 생성 비용은 신규 사용자를 Vaulta로 유입시키는 데 걸림돌이 됩니다. 네트워크는 상당한 유휴 RAM을 보유하고 있으며(예: fund.wram 하나만으로도 약 42.08 GiB의 유휴 RAM, 즉 ram_quota 45,181,400,197바이트 중 3,120바이트 사용, 2026-08-08 기준), 이를 계정 생성에 활용할 수 있습니다.
• 생성자 자금 조달: 생성자로 등록된 온보딩 서비스는 계정 생성을 판매하고 수익의 100%를 가질 수 있습니다. 네트워크는 직접 비용을 지불하지 않으며, 그 대가는 사용자 성장입니다. RAM 비용이 기금으로 충당되므로 판매 가격은 곧 생성자의 마진이 됩니다.
• 시장 중립성: 이 프로그램은 giftram 메커니즘을 사용하므로, 기증된 RAM은 수령자를 통해 Bancor 풀로 다시 유입될 수 없습니다. 이 프로그램은 RAM을 판매하지 않고 성장에 지출합니다.
• 제한된 자기거래(이익 제로는 아님): 기증된 RAM은 생성자든 수령자든 누구도 Bancor 풀에 되팔 수 없으므로, 대량 계정 생성을 토큰 이익으로 전환할 수 없습니다. 다만 저장 공간으로는 여전히 사용할 수 있습니다. 생성자는 일일 쿼터를 자신이 통제하는 계정으로 돌려 네트워크가 부담하는 무료 상태 저장 공간을 축적할 수 있으며, 이는 생성자당 일일 쿼터로 제한되고 RAM이 점유되면 되돌릴 수 없습니다. 쿼터는 이 소진 속도를 제한할 뿐, RAM을 무가치하게 만들지는 않습니다.

메커니즘

계정 및 권한

• ram.vaulta는 다른 *.vaulta 계정들과 동일한 패턴을 따라 BP MSIG(15/21)을 통해 생성됩니다(VP-0002 참고).
• owner/active 권한은 네트워크 거버넌스가 보유합니다. active는 ram.vaulta@eosio.code를 포함하므로 컨트랙트가 자체 권한으로 인라인 giftram을 전송할 수 있습니다.
• 생성자는 계정의 네이티브 권한에 존재하지 않습니다. 이들은 컨트랙트 레지스트리 테이블의 행으로 관리되며, 관리자 액션을 통해 MSIG로 관리됩니다.

컨트랙트 인터페이스

위 필드명은 배포되는 ABI의 실제 필드명입니다. 레지스트리 행: 생성자 계정, 일일 쿼터(바이트), 현재 윈도우에서 사용된 바이트, 윈도우 시작 시각. 건당 기증 상한은 없으며, 일일 쿼터가 전체 지출을 제한하고 생성자가 계정당 지급량을 결정합니다. 각 기증은 기증된 바이트에 더해 기증 계정에 수증자당 청구되는 136바이트의 giftedram 행 오버헤드만큼 쿼터에서 차감되므로(Vaulta 메인넷 트랜잭션 f2c6200c1add5ffc74837bcae1731ff5a66e259376eee6a4d4d7580f044a0b4c에서 확인: 3,000바이트 기증이 기증자에게 정확히 136바이트의 행 오버헤드를 청구함. Jungle 4 테스트에서도 동일한 상수가 4,000 + 136 = 4,136으로 나타남), 쿼터는 명목상 기증 크기가 아니라 실제 기금 소비량을 제한합니다.

쿼터 윈도우의 의미론은 남용 계산의 상한을 정하므로 정확히 명시합니다.

• 24시간 윈도우는 지연 슬라이딩 윈도우입니다. 리셋 후 첫 기증 시점에 시작되며, 그로부터 24시간 이상 지난 뒤의 첫 기증에서 리셋됩니다. 고정된 일 단위 경계가 아니므로, 생성자는 한 윈도우의 끝에 쿼터 전량을 지출하고 윈도우가 넘어간 직후 다시 전량을 지출할 수 있어, 단기 최악의 버스트는 일일 쿼터의 약 2배입니다.
• 생성자 전체에 걸친 전역 상한은 없습니다. 총 최악 소진 속도는 등록된 모든 생성자의 일일 쿼터 합계이며, 신규 생성자 승인과 쿼터 증액이 모두 15/21 액션이므로 이 값은 BP가 승인할 때에만 증가합니다.
• 생성자를 제거한 뒤 재등록하면 현재 윈도우의 사용량이 리셋됩니다. setquota는 사용량 리셋 없이 쿼터만 조정합니다.

기본 쿼터

신규 승인 생성자의 기본 일일 쿼터는 1 MB/일로, 약 3KB짜리 소규모 계정 기준 하루 약 300개에 해당합니다(건당 136바이트 오버헤드 포함). 이 수치는 잠정적입니다. 출범 전후로 활발한 생성자 계정(예: gm)의 실제 생성량을 분석해 조정해야 하며, 변경 역시 15/21 setquota 결정입니다.

생성자 등록 절차

프로그램은 등록된 생성자가 전무한 상태로 출범하며, 승인 요건은 의도적으로 최소화되어 있습니다. 생성자가 되기 위해 필요한 것은 단 하나, addcreator(creator, daily_quota_bytes)를 담아 통과된 15/21 BP MSIG입니다. 신청은 신청자가 선택한 공개 경로를 통해 다음을 공개해야 합니다.

• 등록할 계정,
• 운영 주체와 할당량을 사용할 제품 또는 흐름,
• 요청하는 일일 쿼터(기본값은 1 MB/일).

이 저장소에 제안서를 제출하는 것은 선택적인, 보다 공식적인 신청 경로입니다. BP가 검토할 수 있는 영구적인 문서와 여론 추적을 제공하므로 신청의 성사 가능성을 높일 수 있으나, 요건은 아닙니다. 이 절차 없이 addcreator MSIG를 통과시킬 수 있는 신청자는 그렇게 해도 무방합니다.

사용 패턴

생성자는 단일 서명으로 하나의 트랜잭션 안에서 계정을 생성합니다.

1. eosio::newaccount: 생성 주체는 등록된 생성자의 계정입니다(예: gm이 foo.gm을 생성; 프리미엄 접미사 규칙은 평소와 동일하게 적용).
2. ram.vaulta::giftacct(creator, foo.gm, bytes, memo): 컨트랙트가 인라인 giftram을 전송합니다.

이는 시스템 컨트랙트 및 Spring 소스 코드로 검증되었습니다.

• giftram은 기증자의 권한만 요구하며(delegate_bandwidth.cpp), 이는 eosio.code를 통해 인라인으로 충족됩니다. 네트워크 계정은 결코 서명하지 않습니다.
• giftram은 실행 시점에 수령자가 존재하는지 확인하며, newaccount는 같은 트랜잭션에서 먼저 실행됩니다.
• 컨트랙트는 이 쌍을 강제합니다. giftacct는 패킹된 트랜잭션(read_transaction)을 읽어, account를 생성하는 최상위 eosio::newaccount가 없으면 거부합니다. 계정 생성 밖에서는 구조적으로 기증이 불가능합니다.
• 신규 계정의 RAM 청구는 트랜잭션 종료 시점(Spring transaction_context::finalize)에 검증되므로, 인라인 기증이 신규 계정의 사용량을 충당합니다. 이는 고전적인 newaccount + buyrambytes 패턴이 의존하는 것과 동일한 메커니즘입니다. 계정은 RAM을 보유하게 되는 즉시(기증 자체가 이를 유발함) 시스템의 표준 무료 1,400바이트(ram_gift_bytes)도 받으므로, 필요한 기증 크기가 줄어듭니다.

기금 조성

• 초기 시드: ramtransfer를 통해 admin.grants에서 1~2GB를 이전받습니다(약 3KB짜리 소규모 계정 30만 개 이상에 해당). admin.grants는 과거에도 RAM을 배포한 이력이 있어 이 경로는 이미 검증되었습니다. 비율에 유의: admin.grants는 2026-08-08 기준 ram_quota 2,812,891,144바이트(약 2.62 GiB)를 보유하므로, 2GB 시드는 이 계정 전체 잔액의 상당 부분에 해당합니다.
• 장기 예비 재원: fund.wram(약 42.08 GiB, 유휴 상태, 2026-08-08 기준)이 향후 재원으로 지목되었으며, 프로그램이 실적을 쌓은 후 후속 MSIG를 통해 활용될 예정입니다. 컨트랙트는 RAM의 출처에 의존하지 않습니다.

남용 대응

• 1차 방어선으로서의 쿼터: 생성자별 일일 바이트 쿼터는 소진 속도를 제한하고, 생성자가 자신이 통제하는 계정에 RAM을 공급하는 자기거래(self-dealing)를 그 속도로 제한합니다. 쿼터가 기증 자체뿐 아니라 수증자당 행 오버헤드까지 차감하므로, 다수의 소액 기증으로도 쿼터가 암시하는 속도보다 빠르게 기금을 소진할 수 없습니다. 남용은 하룻밤 사이의 소진이 아니라 탐지 윈도우 내에서 온체인으로 눈에 띄는 추세로 드러납니다.
• 프로그램을 통한 괴롭힘(griefing) 불가: 단일 기증자 규칙으로 인해 단 1바이트의 기증만으로도 해당 계정은 다른 누구로부터도 기증 RAM을 받을 수 없게 됩니다. giftacct는 같은 트랜잭션에서 생성된 계정에만 접근하므로, 이 프로그램은 기존 계정을 괴롭히는 데 사용될 수 없습니다. 직접적인 eosio::giftram을 통한 동등한 공격 경로는 시스템 컨트랙트 영역의 문제이며 본 제안의 범위 밖입니다.
• 생성자 키 탈취: 즉각적인 구제 수단은 생성자 자신에게 있습니다. 키를 교체하면 공격자는 즉시 축출되며, 거버넌스 개입 없이 등록 상태도 그대로 유지됩니다. 이 경우를 위한 컨트랙트 액션은 필요하지 않으며 제공되지도 않습니다.
• 생성자 제거: 악의적이거나 활동을 중단한 생성자는 15/21 MSIG의 rmcreator/setquota로 제거하거나 쿼터를 0으로 만들 수 있으며, 21명 중 15명의 BP 서명을 모으는 데는 몇 분이 아니라 며칠이 걸립니다. MSIG가 모이는 동안의 노출 규모는 일일 쿼터에 그 기간을 곱한 값입니다. 기본값 1 MB/일과 비관적인 5일 기간을 가정하면 약 5 MB로, 감내하기로 한 손실입니다. 그 기간에 기증되어 점유된 바이트는 회수할 수 없습니다(회수 항목 참고).
• 회수: 배포된 시스템 컨트랙트에서 ungiftram은 수증자가 주도해야 하며, 기증자에게는 일방적인 회수 권한이 없습니다. BP는 15/21 하에서 eosio.wrap을 사용해 수증자의 권한으로 ungiftram을 실행할 수 있으나, 강제 반환은 기증된 바이트가 미사용 상태일 때만 성공합니다. 제거와 강제 반환은 생성자가 추가로 기증하는 것을 막을 뿐, 이미 기증되어 점유된 RAM은 어느 쪽도 회수하지 못합니다. 강제 회수는 사용된 적 없는 기증에 대해서만 가능하므로, 취득한 RAM을 채워 넣는 생성자에는 대응하지 못합니다.
• 시스템 컨트랙트 변경 없음: 본 제안은 eosio.system에 대한 수정을 요구하지 않습니다.

범위 경계

• 본 제안은 시스템을 생성할 뿐 생성자를 등록하지 않습니다. 승인은 이후 생성자당 하나의 15/21 addcreator MSIG로 이루어지며, 생성자 등록 절차 항목에 설명되어 있습니다.
• 기존 계정에 대한 기증은 범위 밖이며 컨트랙트 수준에서 강제됩니다. giftacct는 같은 트랜잭션 내 account에 대한 eosio::newaccount를 요구합니다. 이에 따른 트레이드오프는 생성자가 생성 이후 계정에 RAM을 추가로 지급할 수 없다는 것입니다. 기증은 생성 시점에만 이루어지거나 이루어지지 않습니다.
• 수익 배분 없음: 생성자는 청구하는 금액의 100%를 가집니다. 보조금은 자금 조달 메커니즘일 뿐입니다.
• 이는 new.vaulta(자율 결제 기반 계정 생성, VP-0002 참고)와는 별개입니다. 이 프로그램은 생성자 주도이며, 네트워크가 RAM을 부담합니다.

알려진 제약

• 계정당 단일 기증자: 시스템 컨트랙트는 한 번에 계정당 하나의 RAM 기증자만 허용합니다. 이 프로그램으로 생성된 계정은 네트워크의 기증분을 전액 반환하기 전까지 다른 주체(예: 앱)로부터 RAM을 기증받을 수 없습니다. 자체적으로 RAM을 구매하는 것에는 영향이 없습니다.
• 전액 반환만 가능: ungiftram은 기증분 전체를 반환하며, 부분 반환은 지원되지 않습니다.

미해결 질문

• 인덱싱/모니터링을 쉽게 하기 위해 컨트랙트가 기증마다 로그 액션을 발생시켜야 하는가?
• admin.grants로부터의 정확한 시드 규모(1GB 대 2GB)는?

다음 단계

작동하는 프로토타입이 개발되어 Jungle 4 테스트넷에서 시연되었으며, 그 소스는 contracts/gift에 공개되어 있습니다. 남은 작업으로는 미해결 질문 정리, 컨트랙트의 프로덕션화, MSIG 시퀀스 준비(ram.vaulta 생성, 컨트랙트 배포, eosio.code 설정, 시드 RAM 이전)가 있습니다. 생성자 승인은 시스템 가동 이후 별도의 MSIG로 진행됩니다.