수달페이에서 발생하는 수익을 분배하기 위한 시스템 구축을 고민 중에 있습니다.
그 방법은 토큰을 발행하는 것입니다. 수달토큰 수량에 비례해서 수달페이에서 발생한 수익을 배분하는 시스템을 구축할 것입니다.
스팀에서 토큰 발행을 위해 여러 자료를 참고 있는데, 오래전에 Pocket 토큰 프로토콜이 시도된 적이 있는데, 이것의 전문을 한글로 번역해서 공유합니다. 번역은 Claude 3.5 New가 했습니다.
스팀에서 트큰 발행에 관심 있는 분들께 추천합니다.
POCKET 프로토콜 문서의 번역이 완료되었습니다. 이 프로토콜은 다음과 같은 주요 특징을 가지고 있습니다:
이 프로토콜은 새로운 토큰을 설계할 때 참고할 만한 좋은 예시를 제공합니다. 특히:
POCKET(전자 개념 증명 토큰, K는 묵음)은 Steem 블록체인에서 작동하도록 설계된 하위 토큰으로, Steemit.com과 Busy.org 같은 인터페이스를 통해 사용자가 호출할 수 있는 간단한 명령 세트를 통해 사용자와 상호작용합니다.
사용자는 Steem 게시물(댓글 작업)에 특별히 형식이 지정된 명령을 포함시켜 POCKET 토큰을 자신의 계정에서 다른 Steem 계정으로 전송할 수 있습니다. 제3자가 POCKET 데이터베이스 사본을 유지하도록 인센티브를 제공하기 위해, 각 거래에서 작은 수수료가 차감되어 Steem 블록체인에 거래의 유효성 확인을 최초로 게시한 Steem 계정에 지급됩니다. 이 확인은 전송을 시작한 게시물에 대한 답글로 게시되어 사용자에게 작업에 대한 피드백을 제공하고, 제3자 블록 탐색기나 로컬 클라이언트 소프트웨어에 대한 명시적인 필요 없이 시스템을 유용하게 만듭니다.
이 프로토콜은 이중 지출에 대한 강력한 보호를 보장하면서 가능한 한 간단하게 설계되었습니다.
블록체인 기반 암호화폐는 두 가지 개념적 요소를 가져야 합니다: 블록체인을 생성하는 합의 메커니즘과 블록체인 작업 기록을 "누가 무엇을 소유하고 있는지"에 대한 기록으로 변환하는 결정론적 프로토콜입니다. 많은 면에서 첫 번째가 더 어려운 문제이지만, 우리는 이것이 Steem 블록체인에 의해 충분히 해결되었다고 봅니다. 즉, 우리는 Steem 블록체인을 변경 불가능한 메시지 기록으로 간주할 것입니다.
변경 불가능한 Steem 블록체인이라는 가정하에, POCKET 프로토콜은 암호화폐 문제의 두 번째 부분에 대한 명세입니다: Steem 블록체인의 메시지 기록을 POCKET 시스템의 상태로 변환하는 결정론적 프로토콜입니다. POCKET 사용자는 적절한 형식의 Steem 트랜잭션에 메시지를 포함시켜 POCKET 프로토콜에 메시지를 전달할 수 있습니다.
POCKET 프로토콜은 누구의 소유도 아니라는 점에 주목하십시오. 누구도 이를 통제하지 않습니다. POCKET 시스템 참여자들은 프로토콜에 의해 정의된 토큰이 의미와 가능한 가치를 가진다는 것에 암묵적으로 동의했습니다; 토큰은 어떤 개인이나 단체에 의해 발행되지 않습니다.
POCKET 데이터베이스의 핵심은 어떤 계정이 어떤 토큰을 제어하는지에 대한 명세입니다.
약간의 보조 데이터도 POCKET 데이터베이스에 저장되며, 이는 후속 섹션에서 명확해질 것입니다.
POCKET 계정은 두 가지 속성을 가집니다:
이 문서 전체에서 account라는 이름을 가진 계정의 balance 속성은 account.balance로 참조됩니다.
유효한 POCKET 전송 작업이 실행되면, 작업에 대한 정보가 일시적으로 pending_confirmation으로 저장됩니다. 이 정보는 그 후 제3자에 의해 Steem 블록체인에 다시 게시되어 송신자에게 작업이 성공했음을 확인하고 유용한 정보를 제공합니다. pending_confirmation은 다음과 같은 속성을 가집니다:
Steem 계정이 제네시스 간격 동안 POCKET 지분을 청구한 후, 자신의 지분이 청구되었다는 확인을 요청할 수 있습니다. 이는 이 문서의 뒷부분에서 설명하는 대로 제네시스 포스트에 "confirm"이라는 단어로 답글을 달아 수행됩니다. 이 작업이 수행되면, POCKET 데이터베이스는 의도된 확인이 게시될 때까지 확인이 요청되었다는 기록을 유지해야 합니다. 제네시스 확인은 전송 확인보다 훨씬 적은 정보를 저장하면 됩니다:
Steem 블록 1에서 POCKET은 비활성 상태로 초기화됩니다. 비활성 상태일 때는 POCKET 토큰이 존재하지 않으므로 전송이 불가능합니다. 그럼에도 불구하고 POCKET 프로토콜은 여전히 Steem 블록체인을 스캔합니다. 비활성 기간 동안, 모든 Steem 계정은 초기 분배에서 POCKET 토큰을 받을 자격이 있는지 결정하기 위해 모니터링됩니다. POCKET이 활성화되기 전에 Steem 블록체인에 최소 5개의 댓글 작업을 게시한 계정이 자격이 있는 것으로 간주됩니다. 더 많이 작성해도 보너스는 없으며, 그 미만으로 작성한 경우 부분 크레딧도 없습니다. 에 의한 댓글 작업이 블록체인에 게시될 때마다 의 실행 총계가 증가합니다. 총계가 5에 도달하면 는 자격을 얻습니다. 가 댓글을 삭제해도 총계는 감소하지 않습니다. 이전에 게시된 게시물을 편집하는 댓글 작업도 자격을 위한 유효한 댓글로 간주됩니다. 투표, 리블로그, 팔로우 및 기타 모든 유형의 트랜잭션은 자격 결정과 무관합니다.
POCKET은 다음과 같은 속성을 가진 특별한 댓글 작업이 Steem 블록체인에 포함될 때 활성화됩니다:
author = biophil
title = genesis-pocket
게시되면 이 게시물은 "제네시스 포스트"로 알려집니다. POCKET 사용자들은 이 게시물과 상호작용하여 자신의 토큰을 청구할 것입니다.
이 게시물의 제목은 나중에 변경될 수 있지만, 그것의 permlink는 항상 genesis-pocket으로 남을 것입니다.
적격 계정이 POCKET 제네시스 지분을 청구한 후, 이 지분에 대한 확인을 정확히 한 번 요청할 수 있습니다. 따라서 아직 이 확인을 요청하지 않은 계정의 목록을 유지해야 합니다.
"작업"은 (대부분의 경우) Steem 블록체인에 댓글을 게시하여 수행되는 POCKET 시스템과의 상호작용으로 정의됩니다. 이러한 작업들은 steemit.com과 같은 일반적인 Steem 프론트엔드만을 사용하여 POCKET 토큰을 계정 간에 전송할 수 있도록 설계되었습니다.
"명령"은 (대부분의 경우) Steem 댓글 본문에 포함된 문자열로 정의됩니다. "명령"은 POCKET 데이터베이스에 전달되어 검증되는 메시지인 "작업"을 형성하기 위해 구문 분석됩니다.
POCKET의 처음 14일("제네시스 간격"이라고도 함)에만 연관된 두 가지 특별한 작업이 있습니다:
제네시스 관련 두 작업 외에도 POCKET 시스템에서는 세 가지 핵심 작업이 가능합니다:
genesis 작업은 단 한 번만 실행됩니다. 이는 POCKET 데이터베이스에 POCKET이 시작되었다는 신호입니다.
명령 구문: genesis 작업은 genesis 계정(biophil)이 genesis-pocket이라는 제목으로 최상위 게시물을 게시할 때 실행됩니다.
author = biophil
title = genesis-pocket
유효성: 데이터베이스가 비활성 상태인 경우 genesis 작업이 유효합니다. 그렇지 않으면 유효하지 않습니다.
결과: 유효한 genesis가 실행되면 데이터베이스 상태가 "활성"으로 전환됩니다. 적격 계정 집합이 동결되고, 총 Steem 댓글 작업이 4개 이하인 계정의 기록은 이제 부적격으로 확실히 확인되었으므로 삭제될 수 있습니다.
genesis 계정은 genesis 크레딧을 받습니다(기술적으로 적격하지 않더라도):
biophil.balance += 1000001
마지막으로, genesis가 Steem 블록 번호 genesis_block_num에서 실행되었다고 가정합니다. 그러면 genesis_last_block이라는 새 필드가 POCKET 데이터베이스에 추가되고 genesis_block_num + 403200 값으로 초기화됩니다. 403200은 14일 동안 처리되는 Steem 블록의 대략적인 수입니다.
claim 작업은 특별합니다. 댓글을 다는 것 이외의 다른 작업을 실행하는 유일한 POCKET 작업입니다.
명령 구문: claim을 실행하기 위해, account 계정은 POCKET genesis 게시물을 리블로그해야 합니다. 즉, 다음과 같은 json 페이로드로 Steem custom_json 트랜잭션을 제출해야 합니다:
["reblog",{"author":"biophil","permlink":"genesis-pocket"}]
유효성: claim 작업은 다음 조건을 만족할 때 유효합니다:
Genesis Post가 이미 게시되었음(즉, 데이터베이스 상태가 "활성")
리블로그 명령이 genesis_last_block 이하의 번호를 가진 Steem 블록에 포함됨
account가 Genesis Post가 처음 게시되기 전에 5개 이상의 댓글 작업을 게시함(즉, account가 제네시스 지분에 대해 "적격")
account가 이전에 claim 작업을 실행하지 않음
결과: 유효한 경우, claim은 account에 Genesis Stake의 크레딧을 부여합니다. 즉, 다음과 같은 데이터베이스 업데이트가 이루어집니다:
account.balance += 1000001
이제 account는 단일 제네시스 확인을 받을 자격이 있습니다.
from_account 계정이 실행하는 send 작업에는 두 가지 인수가 있습니다:
amount: 전송할 토큰의 수
to_account: 토큰을 전송할 계정
명령 구문: send 작업은 특별히 형식이 지정된 Steem 댓글 작업을 Steem 블록체인에 포함시켜 POCKET 시스템에 제출됩니다. 본문이 다음으로 시작하는 모든 댓글은 send 작업을 포함할 수 있습니다:
pocketsend:amount@to_account
예를 들어, biophil 계정에 1000 POCKET을 보내고 싶다면, body="pocketsend:1000@biophil"인 댓글을 Steem에 게시합니다 (여기서 따옴표 "는 이것이 문자열임을 나타내지만, 본문 자체에는 포함되지 않습니다).
또한, to_account 바로 뒤에 쉼표(",")가 포함된 경우, 쉼표 뒤의 모든 것은 "메모"로 간주되며 POCKET 검증기에 의해 구문 분석되지 않습니다. 예를 들어, 위의 명령은 다음과 동일합니다:
pocketsend:1000@biophil,이 부분은 메모입니다.
메모를 원하는 경우 쉼표를 포함해야 하며 to_account와 쉼표 사이에 공백이 있으면 안 됩니다.
send 명령의 올바른 형식은 다음 정규 표현식과 매칭하여 확인할 수 있습니다:
^pocketsend:\d+@[a-z][a-z0-9-.]{2,15}(,|$)
즉, "pocketsend:" 다음에 비어있지 않은 정수, "@", 유효한 계정 이름, 그리고 아무것도 없거나 ","와 임의의 문자열이 따라옵니다.
명령을 구문 분석할 때, ":"와 "@" 사이의 모든 것은 amount로 기록되고, "@"와 "," 또는 "EOL" 사이의 모든 것은 to_account로 기록됩니다.
유효성: send 작업은 amount>0이고 from_account.balance >= amount인 경우에만 (현재 데이터베이스 상태에 대해) 유효한 것으로 간주됩니다. POCKET은 to_account가 실제로 등록된 Steem 계정인지 확인하지 않습니다. 이를 통해 현재는 토큰을 사용할 수 없지만 누군가가 연관된 이름을 Steem 계정으로 등록하면 사용 가능해질 POCKET 계정을 "생성"할 수 있습니다.
결과: send 작업이 유효한 경우, 다음과 같은 데이터베이스 업데이트가 이루어집니다:
from_account.balance -= amount
to_account.balance += amount - 1
새로운 대기 중인 확인이 다음 정보와 함께 데이터베이스에 추가됩니다:
account 계정이 실행하는 confirm 작업에는 인수가 없습니다.
명령 구문:
confirm 작업은 특별히 형식이 지정된 Steem 댓글 작업을 Steem 블록체인에 포함시켜 POCKET 시스템에 제출됩니다. 댓글 작업은 parent_permlink가 genesis permlink(genesis-pocket)와 동일하고, parent_author가 genesis 계정(biophil)과 동일해야 하며, 본문은 정확히 다음과 같아야 합니다:
confirm.
유효성:
유효하기 위해서는 다음 두 가지 조건을 만족해야 합니다:
account가 POCKET genesis 지분을 청구했어야 합니다.
account가 아직 confirm 작업을 실행하지 않았어야 합니다.
즉, genesis를 청구한 후에만 확인할 수 있으며, 한 번 이상 확인할 수 없습니다.
결과: 유효한 경우, confirm은 다음과 같은 데이터베이스 업데이트를 초래합니다:
다음에서는 데이터베이스가 pc라고 하는 pending_confirmation 객체를 포함하고 있다고 가정합니다. confirmer 계정이 실행하는 pc와 관련된 confirmation 작업에는 다음과 같은 인수들이 있습니다:
명령 구문:
올바른 확인 명령은 pc.identifier로 식별된 게시물에 대한 답글로 Steem 블록체인에 게시됩니다. 즉, 확인 명령은 parent_author = pc.from_account이고 parent_permlink가 pc.identifier에서 얻어진 댓글의 본문에 포함됩니다. 적절한 형식의 댓글 본문은 다음과 같습니다(마지막 줄을 포함한 모든 줄은 줄바꿈 \n 문자로 끝납니다):
Successful Send of pc.amount
Sending Account: pc.from_account
Receiving Account: pc.to_account
New sending account balance: pc.new_from_balance
New receiving account balance: pc.new_to_balance
Fee: pc.fee
Steem trxid: pc.trxid
명령은 관련 댓글의 본문이 다음 정규 표현식과 일치할 때 적절한 형식으로 간주됩니다:
^Successful Send of \d+\nSending Account: [a-z][a-z0-9-.]{2,15}\nReceiving Account: [a-z][a-z0-9-.]{2,15}\nNew sending account balance: \d+\nNew receiving account balance: \d+\nFee: \d+\nSteem trxid: [a-f0-9]{40}\n
마지막 LF \n 문자 뒤에는 임의의 문자열이 허용되며, 이를 통해 확인자가 원하는 경우 다른 유용한 정보를 포함할 수 있습니다.
유효성: confirmation 작업 op는 데이터베이스에 있는 pending_confirmation 객체 pc와 정확히 일치하는 경우 유효한 것으로 간주됩니다. 즉, op는 다음 기준을 충족해야 합니다:
결과: confirmation 작업이 유효한 경우, 다음과 같은 데이터베이스 업데이트가 이루어집니다:
confirm 작업에 대한 확인 게시는 훨씬 더 간단합니다. 다음에서는 데이터베이스가 pc라고 하는 pending_confirmation 객체를 포함하고 있다고 가정합니다. pc와 관련된 confirmation 작업을 실행하는 confirmer 계정은 다음과 같은 속성을 가집니다:
명령 구문:
올바른 확인 명령은 pc.identifier로 식별된 게시물에 대한 답글로 Steem 블록체인에 게시됩니다. 즉, 확인 명령은 parent_author = pc.account이고 parent_permlink가 pc.identifier에서 얻어진 댓글의 본문에 포함됩니다. 적절한 형식의 댓글 본문은 다음으로 시작합니다(각 줄은 마지막 줄을 포함하여 줄바꿈 \n 문자로 끝납니다):
Success! You claimed a genesis stake of 1000001.
trxid:pc.trxid
마지막 LF \n 문자 뒤에는 임의의 문자열이 허용되며, 이를 통해 확인자가 원하는 경우 다른 유용한 정보를 포함할 수 있습니다.
유효성: confirmation 작업 op는 데이터베이스에 있는 pending_confirmation 객체 pc와 정확히 일치하는 경우 유효한 것으로 간주됩니다. 즉, op는 다음 기준을 충족해야 합니다:
결과: confirmation 작업이 유효한 경우, 다음과 같은 데이터베이스 업데이트가 이루어집니다:
POCKET 사용자가 토큰을 보내고 싶지만 관련 확인에 대한 수수료를 지불하고 싶지 않은 경우가 있을 수 있습니다. 이 경우, 송신자는 게시물에서 send 명령을 실행한 다음 즉시 관련 게시물에 대해 Steem delete_comment 작업을 실행할 수 있습니다.
원래 게시물의 데이터는 블록체인에 포함될 것이므로 send 작업은 유효한 것으로 간주되지만, 게시물이 삭제되었기 때문에 send를 확인하기 위한 답글을 게시할 방법이 없을 것입니다. 이 경우, POCKET은 관련 수수료를 수신 계정에 크레딧으로 제공합니다.
명령 구문: 모든 Steem delete_comment(del_comm으로 표시) 작업은 POCKET delete_confirmation 작업(del_conf로 표시)으로서의 유효성을 검사해야 합니다. 이 작업은 del_comm과 관련된 identifier와 동일한 단일 속성 identifier를 가집니다.
유효성:
del_conf 작업은 POCKET 데이터베이스에 identifier = del_conf.identifier인 하나 이상의 pending_confirmation 객체가 존재하는 경우에 유효한 것으로 간주됩니다.
결과: del_conf 작업이 유효한 경우, pending_confs는 모든 pc에 대해 pc.identifier == del_conf.identifier인 POCKET 데이터베이스의 pending_confirmation 객체 집합을 나타냅니다. POCKET 프로토콜이 새로 게시된 댓글과 편집된 댓글을 구분하지 않기 때문에 하나의 identifier가 둘 이상의 send 작업과 연관될 수 있습니다.
del_conf의 결과는 다음과 같습니다:
for pc in pending_confs:
pc.to_account.balance += pc.fee
delete pc from database
end_for
위의 모든 내용은 confirm 게시물을 삭제하는 POCKET 계정에도 적용됩니다. confirm 요청이 포함된 게시물이 관련 확인이 게시되기 전에 삭제되면, 관련 대기 중인 확인도 삭제됩니다. 이 경우, 수수료는 원래 계정으로 반환됩니다.
### 데이터베이스 초기화
DB.active = False
DB.eligible_accounts = empty # 작성자 계정 이름으로 채워질 예정
### 상수
C.GENESIS_ACCOUNT = biophil
C.GENESIS_TITLE = genesis-pocket
C.GENESIS_PERMLINK = genesis-pocket
C.GENESIS_CREDIT = 1000001
C.GENESIS_INTERVAL = 403200
C.FEE = 1
for STEEM operation op in block:
if DB.active == False:
if op is comment com:
if com.author == C.GENESIS_ACCOUNT:
if com.title == C.GENESIS_TITLE:
DB.active = True
DB.gensis_last_block = 403200
DB.GENESIS_ACCOUNT.balance += C.GENESIS_CREDIT
if com.author not in DB.eligible_accounts:
if com.author가 4개 미만의 댓글을 작성한 경우, 댓글 수에 1을 추가
else if com.author가 정확히 4개의 댓글을 작성한 경우, com.author를 DB.eligible_accounts에 추가
else if DB.active == True:
if op is comment com:
# 제네시스 확인 요청과 전송 트랜잭션 감시
if (com.parent_author == C.GENESIS_ACCOUNT) & (com.parent_permlink == C.GENESIS_PERMLINK): # 즉, 댓글이 제네시스 게시물에 대한 답글인 경우
if com.body == 'confirm':
if DB.(com.author).needs_genesis_confirmation == True:
DB.pending_confirmations.add(확인 정보)
DB.(com.author).needs_genesis_confirmation = False
if com.body.startswith('pocketsend:'):
if com.body가 send 작업(to to_account)으로 파싱되고 com.author가 충분한 잔액을 가진 경우:
DB.(com.author).balance -= 전송 금액
DB.to_account.balance += 전송 금액 - C.FEE
DB.pending_confirmations.add(확인 정보)
# send/genesis 확인 감시
if com.parent_identifier가 DB.pending_confirmations에 있는 경우:
if com.body가 올바른 확인 메시지로 파싱되는 경우:
이 대기 중인 확인을 DB.pending_confirmations에서 제거
if op is delete_comment:
if 삭제된 댓글이 하나 이상의 대기 중인 확인과 관련된 경우:
각 관련 send 확인에 대해, 대기 중인 확인을 삭제하고 수수료를 수신 계정에 크레딧
각 관련 genesis-confirm 확인에 대해, 대기 중인 확인을 삭제하고 수수료를 원래 계정에 크레딧
if block <= DB.genesis_last_block:
if op is reblog:
if 리블로그되는 게시물이 genesis 게시물인 경우:
if 리블로거가 DB.eligible_accounts에 있는 경우:
DB.reblogger.balance += C.GENESIS_CREDIT
DB.reblogger.needs_genesis_confirmation = True
# 프로토콜의 기본 처리 흐름
while True:
# 1. Steem 블록 읽기
current_block = get_next_steem_block()
# 2. 블록 내의 모든 작업 검사
for operation in current_block:
if operation.type == "comment":
# 댓글 내용에서 POCKET 명령어 검색
if has_pocket_command(operation.body):
# 명령어 처리 및 DB 업데이트
process_pocket_command(operation)
elif operation.type == "reblog":
# claim 작업 확인 및 처리
if is_genesis_claim(operation):
process_genesis_claim(operation)
이러한 설계는 블록체인의 데이터를 활용하면서도, 실제 토큰의 상태는 별도로 관리하는 하이브리드 방식을 채택했습니다. 이는 스마트 컨트랙트 없이도 토큰 시스템을 구현할 수 있다는 것을 보여주는 좋은 예시입니다.
Posted through the ECblog app (https://blog.etain.club)