New to Nutbox?

[수달페이] 서비스 수익 배분을 위한 준비

1 comment

etainclub
78
9 days ago15 min read

수달페이에서 발생하는 수익을 분배하기 위한 시스템 구축을 고민 중에 있습니다.

그 방법은 토큰을 발행하는 것입니다. 수달토큰 수량에 비례해서 수달페이에서 발생한 수익을 배분하는 시스템을 구축할 것입니다.

스팀에서 토큰 발행을 위해 여러 자료를 참고 있는데, 오래전에 Pocket 토큰 프로토콜이 시도된 적이 있는데, 이것의 전문을 한글로 번역해서 공유합니다. 번역은 Claude 3.5 New가 했습니다.

스팀에서 트큰 발행에 관심 있는 분들께 추천합니다.

요약

POCKET 프로토콜 문서의 번역이 완료되었습니다. 이 프로토콜은 다음과 같은 주요 특징을 가지고 있습니다:

  • Steem 블록체인 위에서 작동하는 서브 토큰 시스템
  • 단순한 명령어로 토큰 전송 가능
  • 제네시스 기간 동안의 초기 토큰 배포
  • 확인 시스템을 통한 거래 검증
  • 수수료 시스템을 통한 검증자 인센티브
  • 이중 지출 방지를 위한 안전장치

이 프로토콜은 새로운 토큰을 설계할 때 참고할 만한 좋은 예시를 제공합니다. 특히:

  • 간단하면서도 견고한 설계
  • 명확한 규칙과 제약 조건
  • 인센티브 구조
  • 거래 확인 메커니즘
  • 초기 토큰 배포 방식

소개

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 계정은 두 가지 속성을 가집니다:

  • name: 이 Pocket 계정과 연결된 Steem 계정 이름에 해당하는 문자열. POCKET 계정 이름은 표준 Steem 계정 이름 사양(즉, 허용된 형식과 문자 측면에서)을 준수하는 경우 유효한 것으로 간주됩니다.
  • balance: 계정에 속한 전송 가능한 POCKET 토큰의 수를 저장하는 음이 아닌 정수.

이 문서 전체에서 account라는 이름을 가진 계정의 balance 속성은 account.balance로 참조됩니다.

대기 중인 확인

전송 확인

유효한 POCKET 전송 작업이 실행되면, 작업에 대한 정보가 일시적으로 pending_confirmation으로 저장됩니다. 이 정보는 그 후 제3자에 의해 Steem 블록체인에 다시 게시되어 송신자에게 작업이 성공했음을 확인하고 유용한 정보를 제공합니다. pending_confirmation은 다음과 같은 속성을 가집니다:

  • identifier: 원래 전송 명령을 포함한 Steem 게시물과 연결된 "@author/permlink" 문자열
  • amount: 원래 전송 금액
  • from_account: 송신 계정
  • to_account: 수신 계정
  • new_from_balance: 전송 작업 직후의 송신 계정 잔액
  • new_to_balance: 전송 작업 직후의 수신 계정 잔액
  • fee: identifier로 식별된 steem 게시물에 대한 답글로 확인 정보를 게시한 첫 번째 계정을 위해 예약된 수수료
  • trxid: 이 전송 명령을 포함한 정확한 댓글 작업과 연결된 Steem 트랜잭션 ID

청구 확인(Claim Confirmations)

Steem 계정이 제네시스 간격 동안 POCKET 지분을 청구한 후, 자신의 지분이 청구되었다는 확인을 요청할 수 있습니다. 이는 이 문서의 뒷부분에서 설명하는 대로 제네시스 포스트에 "confirm"이라는 단어로 답글을 달아 수행됩니다. 이 작업이 수행되면, POCKET 데이터베이스는 의도된 확인이 게시될 때까지 확인이 요청되었다는 기록을 유지해야 합니다. 제네시스 확인은 전송 확인보다 훨씬 적은 정보를 저장하면 됩니다:

  • identifier: 원래 확인 명령을 포함한 Steem 게시물과 연결된 "@author/permlink" 문자열
  • account: 제네시스 확인을 요청한 계정
  • fee: identifier로 식별된 steem 게시물에 대한 답글로 확인 정보를 게시한 첫 번째 계정을 위해 예약된 수수료
  • trxid: 이 확인 명령을 포함한 정확한 댓글 작업과 연결된 Steem 트랜잭션 ID

DB 활동 상태와 적격 계정

Steem 블록 1에서 POCKET은 비활성 상태로 초기화됩니다. 비활성 상태일 때는 POCKET 토큰이 존재하지 않으므로 전송이 불가능합니다. 그럼에도 불구하고 POCKET 프로토콜은 여전히 Steem 블록체인을 스캔합니다. 비활성 기간 동안, 모든 Steem 계정은 초기 분배에서 POCKET 토큰을 받을 자격이 있는지 결정하기 위해 모니터링됩니다. POCKET이 활성화되기 전에 Steem 블록체인에 최소 5개의 댓글 작업을 게시한 계정이 자격이 있는 것으로 간주됩니다. 더 많이 작성해도 보너스는 없으며, 그 미만으로 작성한 경우 부분 크레딧도 없습니다. 에 의한 댓글 작업이 블록체인에 게시될 때마다 의 실행 총계가 증가합니다. 총계가 5에 도달하면 는 자격을 얻습니다. 가 댓글을 삭제해도 총계는 감소하지 않습니다. 이전에 게시된 게시물을 편집하는 댓글 작업도 자격을 위한 유효한 댓글로 간주됩니다. 투표, 리블로그, 팔로우 및 기타 모든 유형의 트랜잭션은 자격 결정과 무관합니다.

POCKET 활성화

POCKET은 다음과 같은 속성을 가진 특별한 댓글 작업이 Steem 블록체인에 포함될 때 활성화됩니다:

author = biophil
title = genesis-pocket

게시되면 이 게시물은 "제네시스 포스트"로 알려집니다. POCKET 사용자들은 이 게시물과 상호작용하여 자신의 토큰을 청구할 것입니다.
이 게시물의 제목은 나중에 변경될 수 있지만, 그것의 permlink는 항상 genesis-pocket으로 남을 것입니다.

기타 사항

적격 계정이 POCKET 제네시스 지분을 청구한 후, 이 지분에 대한 확인을 정확히 한 번 요청할 수 있습니다. 따라서 아직 이 확인을 요청하지 않은 계정의 목록을 유지해야 합니다.

POCKET 작업

"작업"은 (대부분의 경우) Steem 블록체인에 댓글을 게시하여 수행되는 POCKET 시스템과의 상호작용으로 정의됩니다. 이러한 작업들은 steemit.com과 같은 일반적인 Steem 프론트엔드만을 사용하여 POCKET 토큰을 계정 간에 전송할 수 있도록 설계되었습니다.
"명령"은 (대부분의 경우) Steem 댓글 본문에 포함된 문자열로 정의됩니다. "명령"은 POCKET 데이터베이스에 전달되어 검증되는 메시지인 "작업"을 형성하기 위해 구문 분석됩니다.
POCKET의 처음 14일("제네시스 간격"이라고도 함)에만 연관된 두 가지 특별한 작업이 있습니다:

  • genesis: 이는 단일 사전 지정된 계정에 의해 한 번만 실행되는 특수 작업이며, POCKET 시스템을 "켭니다".
  • claim: 이는 적격 POCKET 계정이 POCKET 프로토콜 참여에 동의하고 제네시스 지분 토큰을 받는 방법입니다.

제네시스 관련 두 작업 외에도 POCKET 시스템에서는 세 가지 핵심 작업이 가능합니다:

  • send: 이 작업을 통해 POCKET 토큰 소유자는 토큰을 다른 Pocket 계정으로 보낼 수 있습니다.
  • confirm: 이 작업을 통해 POCKET 토큰 소유자는 자신이 제네시스 지분을 청구했다는 확인을 요청할 수 있습니다. 각 POCKET 계정은 정확히 한 번의 confirm 작업만 허용됩니다.
  • confirmation: 이 작업을 통해 데이터베이스 유지 관리자는 POCKET send 또는 confirm 작업의 성공을 보고하는 대가로 수수료를 수집할 수 있습니다.

genesis 작업

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 작업

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는 단일 제네시스 확인을 받을 자격이 있습니다.

send 작업

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
새로운 대기 중인 확인이 다음 정보와 함께 데이터베이스에 추가됩니다:

  • ident: 원래 POCKET send 메시지를 포함한 Steem 게시물에 해당하는 Steem 게시물 식별자(@accountname/permlink)
  • trxid: 관련 Steem 게시물이 포함된 트랜잭션에 해당하는 Steem 트랜잭션 ID
  • from_account
  • to_account
  • amount
  • new_from_balance: 거래 후 계산된 수신 계정의 새로운 총 잔액
  • new_to_balance: 마찬가지로 거래 후 계산된 송신 계정의 새로운 총 잔액
  • fee: 확인하는 계정을 위해 예약된 수수료

confirm 작업

account 계정이 실행하는 confirm 작업에는 인수가 없습니다.
명령 구문:
confirm 작업은 특별히 형식이 지정된 Steem 댓글 작업을 Steem 블록체인에 포함시켜 POCKET 시스템에 제출됩니다. 댓글 작업은 parent_permlink가 genesis permlink(genesis-pocket)와 동일하고, parent_author가 genesis 계정(biophil)과 동일해야 하며, 본문은 정확히 다음과 같아야 합니다:
confirm.
유효성:
유효하기 위해서는 다음 두 가지 조건을 만족해야 합니다:

account가 POCKET genesis 지분을 청구했어야 합니다.
account가 아직 confirm 작업을 실행하지 않았어야 합니다.

즉, genesis를 청구한 후에만 확인할 수 있으며, 한 번 이상 확인할 수 없습니다.

결과: 유효한 경우, confirm은 다음과 같은 데이터베이스 업데이트를 초래합니다:

  1. account.balance -= 1
  2. 새로운 대기 중인 확인이 다음 정보와 함께 데이터베이스에 추가됩니다:
  • ident: 원래 POCKET confirm 메시지를 포함한 Steem 게시물에 해당하는 Steem 게시물 식별자(@accountname/permlink)
  • trxid: 관련 Steem 게시물이 포함된 트랜잭션에 해당하는 Steem 트랜잭션 ID
  • account
  • fee: 확인하는 계정을 위해 예약된 수수료

send에 대한 confirmation 작업

다음에서는 데이터베이스가 pc라고 하는 pending_confirmation 객체를 포함하고 있다고 가정합니다. confirmer 계정이 실행하는 pc와 관련된 confirmation 작업에는 다음과 같은 인수들이 있습니다:

  • identifier
  • amount
  • from_account
  • to_account
  • new_from_balance
  • new_to_balance
  • fee
  • trxid

명령 구문:
올바른 확인 명령은 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는 다음 기준을 충족해야 합니다:

  1. Steem 트랜잭션 op.trxid는 관련 send 명령을 초래한 댓글 작업을 포함해야 합니다.
  2. op를 초래하는 명령은 pc.identifier에 대한 답글 본문에 있어야 합니다.
  3. op.amount = pc.amount
  4. op.from_account = pc.from_account
  5. op.to_account = pc.to_account
  6. op.new_from_balance = pc.new_from_balance
  7. op.new_to_balance = pc.new_to_balance
  8. op.fee = pc.fee
  9. op.trxid = pc.trxid

결과: confirmation 작업이 유효한 경우, 다음과 같은 데이터베이스 업데이트가 이루어집니다:

  1. confirmer.balance += op.fee
  2. 데이터베이스에서 대기 중인 확인 pc가 제거됩니다.

confirm에 대한 confirmation 작업

confirm 작업에 대한 확인 게시는 훨씬 더 간단합니다. 다음에서는 데이터베이스가 pc라고 하는 pending_confirmation 객체를 포함하고 있다고 가정합니다. pc와 관련된 confirmation 작업을 실행하는 confirmer 계정은 다음과 같은 속성을 가집니다:

  • identifier
  • account
  • fee
  • trxid

명령 구문:
올바른 확인 명령은 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는 다음 기준을 충족해야 합니다:

  1. Steem 트랜잭션 op.trxid는 pc.identifier와 연관된 이 confirm 작업을 초래하는 댓글 작업을 포함해야 합니다.
  2. op를 초래하는 명령은 pc.identifier에 대한 답글 본문에 있어야 합니다.
  3. op.account = pc.account
  4. op.trxid = pc.trxid

결과: confirmation 작업이 유효한 경우, 다음과 같은 데이터베이스 업데이트가 이루어집니다:

  1. confirmer.balance += op.fee
  2. 데이터베이스에서 대기 중인 확인 pc가 제거됩니다.

delete_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 작업에 대한 참고 사항:

위의 모든 내용은 confirm 게시물을 삭제하는 POCKET 계정에도 적용됩니다. confirm 요청이 포함된 게시물이 관련 확인이 게시되기 전에 삭제되면, 관련 대기 중인 확인도 삭제됩니다. 이 경우, 수수료는 원래 계정으로 반환됩니다.

Pocket 프로토콜 Pseudocode

### 데이터베이스 초기화

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

POCKET 프로토콜의 작동 방식

  1. 기본 동작 원리
  • POCKET은 Steem 블록체인의 데이터를 "읽기 전용" 소스로 사용합니다
  • 실제 토큰의 상태는 별도의 오프체인 데이터베이스에 저장됩니다
  • 프로토콜은 Steem 블록체인의 모든 블록을 순차적으로 스캔하면서 POCKET 명령어를 찾아 처리합니다
  1. 명령어 전달 방식
  • 대부분의 명령어는 Steem의 일반 댓글(comment) 작업을 통해 전달됩니다
  • 예외적으로 claim 작업만 리블로그(reblog) 작업을 사용합니다
  • 명령어는 특정 형식의 텍스트를 댓글 내용에 포함시키는 방식으로 전달됩니다
    • 예: "pocketsend:1000@username"
  1. 데이터베이스 관리
  • 별도의 오프체인 데이터베이스가 필요합니다
  • 이 DB는 다음 정보를 추적합니다:
    • 각 계정의 토큰 잔액
    • 대기 중인 확인들
    • 적격 계정 목록
    • 활성화 상태 및 제네시스 블록 정보
  1. 검증 시스템
  • 모든 거래는 제3자의 확인이 필요합니다
  • 확인자는 거래 내용을 검증하고 이를 댓글로 게시합니다
  • 확인에 대한 보상으로 수수료를 받습니다
  1. 순차적 처리
# 프로토콜의 기본 처리 흐름
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)
  1. 안전성 보장
  • 모든 작업은 결정론적으로 처리됩니다
  • Steem 블록체인의 불변성을 활용해 이중 지출을 방지합니다
  • 모든 상태 변경은 검증 가능하고 재현 가능합니다
  1. 특징
  • 별도의 스마트 컨트랙트 없이 동작
  • 최소한의 기능으로 단순하게 설계
  • Steem의 기존 기능만으로 토큰 전송 가능
  • 제3자 검증을 통한 거래 확인
  • 검증자에 대한 인센티브 제공

이러한 설계는 블록체인의 데이터를 활용하면서도, 실제 토큰의 상태는 별도로 관리하는 하이브리드 방식을 채택했습니다. 이는 스마트 컨트랙트 없이도 토큰 시스템을 구현할 수 있다는 것을 보여주는 좋은 예시입니다.

Posted through the ECblog app (https://blog.etain.club)

Comments

Sort byBest