"토큰부터 발행해두고 세부 조건은 나중에 정리하면 안 됩니까?"
이 질문은 자연스럽습니다. 서비스는 배포한 뒤에 고치는 것이 당연하고, 컨트랙트도 코드이니 같을 것 같습니다.
그런데 컨트랙트는 배포 버튼을 누르는 순간 코드가 아니라 사실이 됩니다.
어떤 항목은 그 뒤에도 고칠 수 있고, 어떤 항목은 영영 고칠 수 없습니다. 그 구분을 배포 전에 알고 있어야 합니다.
배포는 출시가 아니라 결정입니다
서버 배포는 되돌릴 수 있습니다. 문제가 생기면 이전 판으로 돌아가고, 아무도 모르는 사이에 고쳐집니다.
컨트랙트 배포는 다릅니다.
배포된 코드는 공개되고, 그 주소로 사람들이 자산을 보내기 시작하고, 거래소와 지갑과 데이터 사이트가 그 주소를 기준으로 움직입니다.
코드를 고친 새 컨트랙트를 배포할 수는 있지만, 그것은 수정이 아니라 새 토큰입니다. 기존 보유자를 전부 옮겨야 하고, 옮기지 않은 물량은 남습니다.
그래서 배포는 개발 일정의 한 단계가 아니라 사업 조건이 정해지는 시점입니다.
배포 전에 정하지 않은 것은 배포 뒤에 정하는 것이 아니라, 배포 뒤에 정할 수 없게 됩니다.
배포 뒤에는 영영 고칠 수 없는 항목이 있습니다
총 발행량과 발행 방식.
고정 발행인지 추가 발행이 가능한지, 가능하다면 누가 할 수 있는지가 코드에 박힙니다. 나중에 발행량을 늘리고 싶어도 코드가 허용하지 않으면 불가능하고, 허용하면 그 사실 자체가 시장의 평가 항목이 됩니다.
초기 배분의 실행.
배포와 동시에 물량이 어느 지갑으로 갔는지는 온체인에 남습니다. 배분표를 나중에 고쳐도 첫 배분의 기록은 지워지지 않습니다.
권한 구조.
발행, 소각, 일시정지, 차단 같은 관리자 기능이 있는지, 그 권한을 누가 갖는지가 배포 시점에 정해집니다. 권한을 나중에 포기할 수는 있어도 없던 권한을 추가할 수는 없습니다.
전송 조건.
전송에 제한을 걸 수 있는 표준인지 아닌지는 배포 순간 정해집니다. 규제 요건상 제한이 필요해진 뒤에 그 기능이 없다는 것을 알게 되면 선택지는 재발행뿐입니다.
배포 뒤에도 고칠 수 있는 항목은 따로 있습니다
| 항목 | 왜 고칠 수 있는가 |
|---|---|
| 락업과 해제 일정 | 별도 컨트랙트나 제3자 보관으로 관리한다면 조정할 수 있습니다. 다만 이미 합의한 상대가 있으면 그 조정은 대화가 필요합니다 |
| 유통 계획 | 배포된 물량 중 언제 얼마를 시장에 내놓을지는 팀의 운영 판단입니다. 코드가 아니라 계획입니다 |
| 운영 규칙 | 초기에는 팀이 결정하다가 나중에 참여자에게 넘기는 구조는 흔하고, 그 전환은 배포 뒤에 설계할 수 있습니다 |
| 업그레이드 가능한 부분 | 처음부터 업그레이드 가능하게 설계했다면 논리는 고칠 수 있습니다. 대신 "누가 업그레이드할 수 있는가"라는 권한이 생깁니다 |
마지막 항목의 권한은 외부가 반드시 확인하는 사항이 됩니다. 그 판단도 배포 전에 내려져야 합니다.
"나중에 정리"는 두 목록에 대입하면 뜻이 반으로 나뉩니다
세부 조건을 나중에 정리한다는 말을 위의 두 목록에 대입해 보면 뜻이 분명해집니다.
락업 일정과 유통 계획을 나중에 정리하는 것은 가능합니다.
발행량과 권한 구조와 전송 조건을 나중에 정리하는 것은 불가능합니다.
그래서 "토큰부터 발행하고"라는 문장은 반으로 나뉩니다.
앞부분의 결정 항목이 정해져 있다면 발행해도 됩니다. 정해져 있지 않다면 발행은 정리를 미루는 것이 아니라 정리할 기회를 없애는 것입니다.
FD인터내셔널이 토큰을 먼저 만드는 것 자체를 막지 않는 이유이기도 합니다. 토큰을 먼저 만드는 것이 프로젝트의 목표를 달성하기 위해 필요한 전략이라면 그 선택도 충분히 가능합니다.
다만 그 경우에도 영영 고칠 수 없는 목록만은 배포 전에 답이 있어야 합니다.
배포 전에 정해야 하는 목록은 한 장이면 됩니다
- 총 발행량과 추가 발행 가능 여부, 가능하다면 누구의 권한인가
- 초기 배분의 지갑별 물량, 그리고 그것이 백서와 계약서의 숫자와 같은가
- 관리자 권한의 종류와 보유자, 그 권한을 언제 어떻게 축소할 것인가
- 전송 제한이 필요한 규제 요건이 있는가 (이 판단은 법무법인의 검토가 필요한 영역입니다)
- 업그레이드 가능 여부와 그 권한
이 다섯 줄에 답이 없는 상태로 배포하면, 답이 나온 뒤에 할 수 있는 일은 재발행뿐입니다.
재발행은 기술 작업이 아니라 보유자 전원과의 대화입니다.
권한이 모자라도 넘쳐도 배포 뒤에는 같은 대화가 반복됩니다
FD가 반복해서 보는 장면은 두 가지입니다.
하나는 이미 배포된 컨트랙트에 필요한 권한이 없어서 규제 대응을 못 하는 경우입니다. 배포 당시에는 규제 요건을 검토하지 않았고, 요건이 생긴 뒤에는 코드가 허용하지 않았습니다.
다른 하나는 반대로 권한이 너무 많아 심사에서 걸리는 경우입니다. 안전을 위해 넣어둔 관리자 기능이 "팀이 마음대로 할 수 있는 토큰"으로 읽혔습니다. 권한을 포기하는 것으로 해결되지만, 그 포기가 다시 신호가 됩니다.
두 장면 모두 배포 전 한 장의 목록으로 막을 수 있었던 일입니다.
가장 저렴하게 실수를 수정할 수 있는 시점은 실행하기 전이고, 컨트랙트에서 실행은 배포입니다.
기술은 사업을 위해 존재합니다. 컨트랙트를 어떻게 짤 것인가보다, 이 사업이 무엇을 되돌릴 수 없게 만들 것인가가 먼저입니다.