테조스 백서(한글)

Tezos — a self-amending crypto-ledger White paper
자가 수정형 암호화 원장 백서

L.M. Goodman
2014년 9월2일

번역 @areyoucrazy
기획 @krexchange

3.2. POS 메커니즘

3.2.1. 전반적인 오버뷰

우리들의 POS 메커니즘은 slasher, 체인-오프-활동(chain-off-activity), Proof-of-burn등 여러 아이디어들의 섞인 형태로 이루어져 있습니다. 다음 내용은 알고리즘의 오버뷰이며, 알고리즘의 구성 요소들은 아래에서 보다 자세히 설명이 됩니다.

각 블록들은 임의의 스테이크 홀더(채굴자)가 채굴하게 되며, 임의의 스테이크 홀더들이 제공한 이전 블록의 여러 서명들을 포함하게 됩니다. 채굴와과 서명 모두 작은 보상을 받지만, 만드는데 이중 채굴나이나 이중 서명의 경우 몰수 안전 보증금이 몰수되기에 1년의 시간이 소요(UNBONDING은 1년이 아닌 1 주기내로 이루어질 가능성이 더 큽니다) 됩니다.

이 프로토콜은 2048 블록 주기 사이에서 펼쳐지게 됩니다. 각 사이클이 시작될 때, 채굴을 한 사용자가 선택하고 마지막에서 두 번째 주기에 넣은 숫자로부터 무작위의 씨드가 파생되고 마지막에 공개가 됩니다. 이 무작위의 씨드를 이용하는 동시에 코인 전략이 사용되어 채집 권리와 다음 주기를 위한 특정한 주소에 계약할 권리가 주어집니다. 그림1을 참조하십시오.

3.2.2. 시계

프로토콜은 블록 간에 최소 지연을 부과합니다. 원칙적으로 각 블록은 그 어떠한 스테이크 홀더일지라도 채굴이 가능합니다. 하지만, 주어진 블록에 대해서 각 스테이크 홀더들은 임의의 최소 지연이 적용되게 됩니다. 예를 들어서 최고 순위를 받게 되는 스테이크 홀더는 이전 블록을 채굴하게 된 후 1분이면 다음 블록을 채굴 할 수 있을 것입니다. 두번째 순위를 받게 되는 스테이크 홀더는 이전 블록 이후 2분을 기다리게 될 것이고, 세번째 순위를 받게 되면 이전 블록 이후 3분을 기다리게 될 것입니다.

이렇게 함으로써 소수의 스테이크 홀더들이 기여하게 되는 포크는 낮은 블록 생성 비율을 나타내게 됩니다. 이렇지 않을 경우에는 노드를 속여서 그저 길기만 한 체인 높은 점수를 받았다고 속여서 CPU 서비스 거부 공격이 일어날 수도 있습니다.

3.2.3. 랜덤 시드 생성

채굴 된 모든 블록은 채굴자가 선택한 임의의 번호로 해시 커밋을 전달합니다. 이 번호는 안전 bond를 몰수하게 되는 페널티 때문에 다음주기에 공개하게 됩니다. 이 페널티는 씨드의 엔트로피를 공격하는데 사용될 수 있는 번호들의 선택적인 보류를 방해하기 위해서 주어지게 됩니다.

다음 주기의 악의적인 광부들은 이러한 계시들을 검열하려고 시도할 수도 있지만, 하나의 블록에 여러 개의 숫자가 나타날 수 있기 때문에, 성공 가능성은 매우 낮습니다.

한 주기에서 공개된 모든 번호는 해시 목록에 결합되게 되며, 씨드는 암호화 키 유도 함수를 이용하여 루트(root)에서 파생되게 됩니다. 핵심적으로 파생된 것은 씨드를 파생하는 시간이 일반적인 Pc에서 평균적인 승인 시간의 몇퍼센트의 일부분의 시간으로 요청을 받아드릴 수 있도록 조정을 해야 합니다.

그림1: POS 메커니즘의 4가지 단계

3.2.4. 코인을 따라가는 절차 (follow-the-coin procedure)

스테이크 홀더를 랜덤하게 고르기 위해서 우리는 이러한 절차를 따릅니다.

핵심

이 아이디어는 사토시의 비트 코인에서는 사토시를 따르라 라고도 알려져 있습니다. 이 절차는 마치 채굴된 모든 사토시가 고유한 일련 번호가 적혀 있듯이 작용합니다. 사토시들은 암시적으로 생성 시간에 따라 정렬되며, 임의의 사토시가 블록체인을 통해서 그려지고 추적이 되게 됩니다. 여기서 물론 개별 센트는 직접 추적되지 않습니다. 그 대신에 입력이 결합되어 여러 출력에 걸쳐 사용될 때, 어떤 일이 발생하는지 설명하기 위해서 규칙이 적용되게 됩니다.

결국 알고리즘은 각 키와 관련된 사이(간격들(interval))의 집합들을 추적합니다. 여기서 각 간격들은 사토시의 범위를 나타내게 됩니다. 하지만 안타깝게도 시간이 지나면 지날수록 데이터베이스는 점점 단편화 되게 되어서 클라이언트 쪽에서 이것이 부풀어 오르게 됩니다.

코인 롤 (Coin Rolls)

따라서 우리는 10000tez로 이루어진 “코인 롤”을 구성하여 이전의 알고리즘을 최적화합니다. 따라서 100만개의 롤이 존재하며, 데이터 베이스는 모든 롤을 현재 소유자에게 매핑하게 됩니다.

각 주소에는 일정한 롤 세트와 함께 작은 변경 사항들을 느슨하게 적용시킬 수 있는 능력을 가지고 있습니다. 전체 롤에서 일부를 쓰기를 원할 때에는 롤이 끊어지게 되며, 일련변호가 LIFO줄의 롤(일종의 림보)로 보내지게 됩니다. 모든 트랜잭션은 손상된 롤 수를 최소화 시키는 방식으로 처리되며, 주소에 롤을 형성할 코인이 충분하게 있다면 일련번호가 다시 대기열에 놓이고 롤이 다시 형성되게 됩니다.

LIFO의 우선 순위는 비밀 포크에서 작업하고 있는 공격자가 계정간의 변경 사항을 뒤섞어서 코인을 변경할 수 없게 하는 것입니다.

이 방법의 작은 단점은 스테이크가 롤들의 가까운 정수로 정해진다는 것입니다. 하지만, 이는 사토시의 방식에 비해서는 효율성에서 엄청난 향상을 제공하게 됩니다.

롤들에 번호가 매겨지지만, 이 접근법은 Zerocash 와는 다르게 대체가능한 보존형 프로토콜(fungibility preserving protocol)의 사용을 배제하지 않습니다. 그러한 프로토콜은 같은 림보 큐 기술을 사용할 수 있습니다.

Motivation

이 절차는 가중치가 부여된 임의의 주소를 뽑아내는 것과는 기능적으로 다릅니다.
사실 비밀 포크에서는 채굴자들은 임의의 시드 생성을 제어하고 적절한 주소를 미리 작성하여 서명 및 발행 권한을 할당하려고 시도할 수 도 있습니다. 이러한 부분들은 롤들이 무작위로 선택될 때 더욱 어려워질 것입니다. 왜냐하면 비밀 포크는 특정 롤의 소유권을 위조할 수 없고, 서명 및 발행 권한을 할당하기 위해선 시드에 적용된 해시 함수를 이미지화해야 하기 때문입니다.
실제로 한 길이가 N=2048인 주기에서 f만큼의 롤의 부분을 가진 사람은 평균적으로 fN만큼의 채굴 권한을 가지게 될 것이며, 수령한 부분의 구간인 f0의 표준편차는:

공격자가 만약 W개의 다른 씨드를 통해서 공격을 했을 때 그의 예상되는 최대 이득인

블록 수 입니다. 예를 들어서 공격자가 f=10%의 롤들을 조정한다면, 매 주기마다 205개의 블록들을 캐낼 것입니다. 이렇게 된다면, 그가 시도하는 비밀 포크에서 씨드를 제어하기 위해서 1조개가 넘는 해시를 계산했다고 가정하면 약 302개의 블록 또는 블록의 약 14.7%를 할당할 수 있을 것입니다. 다음을 유의 하십시오:

• 씨드가 파생된 해시는 값비싼 키 파생 함수로 무차별 검색은 비실용적입니다.
• 채굴된 블록에서 선형 이득을 보기 위해서는 공격받은 사람들은 quadratically exponential effort를 늘려야할 것입니다.

3.2.5. 블록 채굴

랜덤 시드는 반복적으로 롤을 선택하는데 사용됩니다. 선택된 첫번째 롤이 스테이크 홀더가 1분뒤에 채굴할 수 있게 한다면, 그 다음엔 2분후에 가능할 것이며, 같은 맥락으로 흘러갈 것입니다.

스테이크 홀더가 씨드를 관찰하다가 그가 다음 주기에서 우선 순위의 블록을 채굴할 수 없다는 것을 알았을 때, 그는 보안 보증금을 낼 수 있습니다.

잠재적으로 문제가 되는 상황을 피하기 위해 만약 아무 스테이크 홀더가 블록을 캘 때 보안 보증금을 내지 않았더라면, 16분뒤에 그 블록은 보증금 없이 채굴이 가능합니다.

Bond들은 암시적으로 블록을 채굴하지 않는 체인의 구매자에게 즉시 반환되게 됩니다.

3.2.6. 서명 블록

알고 있듯이, 우리는 작동직전의 POS 시스템을 가지고 있습니다. 우리는 체인의 무게로 블록 개수를 정의할 수 있습니다. 하지만, 이것은 이기적인 채굴의 형태로 이어질 것입니다.

따라서 우리는 서명 방식을 소개 합니다. 블록이 발행되는 동안 무작위의 시드는 16개의 롤에 16개의 서명 권한은 무작위로 할당하는데 사용됩니다.

이러한 서명 권한을 받은 스테이크 홀더들은 블록들이 발행되는 것을 관찰한다음에 서명을 승인합니다. 그런 다음에 그 서명은 그 블록체인에 부모(이전 체인)의 포함을 확보하려는 채굴자들에 의해 다음 블록에 포함됩니다.

서명자가 받는 서명 보상은 블록과 그 전 블록 사이의 시간 간격에 반비례 합니다. 따라서 서명자들은 그들이 서명하는 블록이 최선의 블록이라는 것에 대해서 믿고 서명하는 것에 강력한 동기 부여가 되게 됩니다. 그들은 또한 블록이 블록체인에 포함될 경우에만 보상금을 받기 때문에, 어떠한 블록을 서명해야 할지에 대한 구분도 할 수 있습니다.

가장 우선 순위에 있는 블록이 채굴되지 않는 경우(광부가 대기하지 않았을 경우가 큽니다) 기다리는 서명자들에겐 인센티브가 주어집니다. 하지만 다른 서명자들은 그때 우선 순위 블록을 서명하기로 결정할 수 있으며, 그렇게 되면 새로운 블록들이 서명을 받게 되어 이전 대기열이 풀리지 않을 수도 있습니다. 따라서 광부들은 이 전략을 따르지 않을 가능성이 큽니다.

반대로, 예를 들면 서명자가 공황상태에 빠져 첫번째 블록에 서명하기 시작하는 상황을 생각할 수 있습니다. 다른 서명자가 그렇게 하고, 새로운 블록을 즉시 만들 수 있다는 두려움 때문입니다. 그러나 이는 아무 에게도 도움이 되지 않는 말이 되지 않는 상황입니다. 이런 방식으로 행동할 정도로 프로그램 코드를 수정하는 것도 불가능하고, 이러한 균형이 가능할 것이라고 서명자가 생각할 동기마저 없기 때문입니다. 악의적으로 운영을 혼란 시키려는 사람은 다른 이들이 이 전략을 따르지 않을 것이기 때문에, 스스로 피해만 입게 되는 상황이 일어날 것입니다.

3.2.7. 체인의 무게

체인의 무게는 서명의 수와 같습니다.

3.2.8. 폐기

블록의 이중 발행이나 이중 서명을 막기 위해서 광부는 그의 블록에 폐기 통보를 포함시킬 수 있습니다.

이 폐기 처분은 두가지 형태의 서명을 필요로 합니다. 각각의 발행 서명이나 블록 서명은 블록의 높이를 표시해서 불법 행위의 증거를 간결하게 만들어줍니다.

우리가 불법 행위를 비난할 수는 있어도, 블록을 채굴하는 광부를 초월해서 무언가를 하는 것은 불가능합니다.

사실 광부는 불법 행위에 대해서 증거를 복사한 후 자신의 발견으로 보고할 수 있습니다.
또한, 당사자가 이중 승인이나 이중 서명으로 인해서 범죄를 저질렀다는 사실이 발견되면, 안전 bond는 박탈이 되게 됩니다.

3.3. 스마트 컨트랙트

3.3.1. 스마트 컨트랙트 종류

사용하지 않은 출력 대신 테조스는 상태 저장 계정을 사용합니다. 이러한 계정이 실행 코드를 저장하게 되면 우리가 아는 컨트랙트가 됩니다. 계정은 컨트랙트 유형이기에 우리는 이 두가지를 모두 보편적인 계약으로 지정하게 됩니다.

각 컨트랙트는 관리자가 있으며, 계정의 경우 단순히 소유자로 여겨지게 됩니다. 컨트렉트에 쓸모가 있다고 표시가 된 경우, 관리자는 컨트렉트에 관련된 자금을 사용할 수 있게 됩니다. 또한 각 컨트렉트는 POS 프로토콜에서 블록 서명이나 채굴에 사용되는 공개 키의 해시를 지정할 수 있습니다.

개인 키는 관리자가 제어할 수도 있으며, 하지 않을 수도 있습니다.
형식적으로 계약은 다음과 같이 표현이 됩니다.

type contract = {
   counter: int; (* counter to prevent repeat attacks *)
   manager: id; (* hash of the contract 's manager public key *)
   balance: Int64.t; (* balance held *)
   signer: id option; (* id of the signer *)
   code: opcode list; (* contract code as a list of opcodes *)
   storage: data list; (* storage of the contract *)
   spendable: bool; (* may the money be spent by the manager? *)
   delegatable: bool; (* may the manager change the signing key? *)
}

컨트랙트에서의 핸들은 초기 내용의 해시입니다. 해시가 기존 컨트렉트와 충돌되는 컨트렉트를 만들 려고 하면 이는 잘못된 연산으로 판단되어서 올바른 블록에 포함 시킬 수 없습니다.

데이터는 공용체 유형으로 다음과 같이 표시 됩니다:

type data =
   | STRING of string
   | INT of int

여기서 INT는 부호가 있는 64-비트 정수이며, 스트링은 최대 1024 바이트의 배열입니다. 저장 용량은 정수로 8바이트로, 문자열을 길이로 계산했을 때, 16384 바이트로 제한이 됩니다.

3.3.2. 생성

생성 작업은 새로운 계약을 생성하는데 사용될 수 있고, 계약의 코드 및 계약의 저장소의 초기 내용을 특정합니다. 핸들이 이미 존재하는 컨트랙트의 핸들이면 생성은 거부되게 됩니다. (이러한 경우는 실수나 악의가 있는 경우를 제외하고는 발생할 일이 없습니다) 컨트랙트를 유지하려면 최소 잔액이 1이상 이어야하며, 그 숫자보다 낮게 되면 컨트랙트는 파괴됩니다.

3.3.3. 트랜잭션들

트랜잭션은 한 컨트랙트에서 다른 컨트랙트로 전해진 메시지며, 아래와 같이 표현 됩니다.

type transaction = {
   amount: amount; (* amount being sent *)
   parameters: data list; (* parameters passed to the script *)
   (* counter (invoice id) to avoid repeat attacks *)
   counter: int;
   destination: contract hash;
}

위와 같은 트랜잭션은 관리자의 키를 이용해서 서명되었을 경우엔 컨트랙트에서 전송하거나, 컨트랙트 내에서 실행되는 코드를 통해서 프로그래밍 방식으로 전송할 수 있습니다. 트랜잭션이 수신되면, 해당 금액이 도착지의 컨트랙트 잔고에 더해지며, 도착지의 컨트랙트 코드는 삭제 되게 됩니다. 이 코드는 전달된 매개 변수를 사용할 수 있으며, 컨트랙트의 저장소를 읽고 쓸 수 있고, 서명키를 변경하거나 트랜잭션을 다른 컨트랙트로 전송할 수 있습니다.

카운터의 역할은 재생 공격을 막는 것입니다. 트랜잭션은 컨트랙트의 카운터가 트랜잭션의 카운터와 동일한 경우에만 유효합니다. 트랜잭션이 적용되게 된다면, 카운터는 1씩 증가하게 되어서 트랜잭션이 재사용되지 않도록 막게 됩니다.

또한 트랜잭션에는 클라이언트가 유효하게 간주하는 최근 블록의 블록 해시도 포함합니다. 공격자가 포크로 긴 재구성 작업을 강요하게 되는 경우, 그는 이러한 트랜잭션을 포함시키지 못할 것이며, 포크가 거짓이라는 것은 쉽게 들통이 나게 될 것입니다. 이것은 마지막 방어선이며TAPOS라고 불리는 이 시스템은 장기적인 재조직을 방지하지만, 단기적인 이중 지출을 방지하는 시스템은 아닙니다.

이 쌍(account_handle,counter)는 대략적으로 비트 코인에서의 사용되지 않는 출력과 같습니다.

3.3.4. 저장료

저장 장치가 네트워크에 비용을 부과하기 때문에, 저장 장치의 각 바이트 증가에 대해서 최소 1ꜩ의 요금이 부과 됩니다. 예를 들어서 트랜잭션 실행후 정수가 저장 영역에 추가 되고, 저장 장치의 기존 문자열에 10자가 추가되게 된다면 18ꜩ이 계약의 잔고에서 철회되어 폐기되게 됩니다.

3.3.5. 코드

언어는 스택 기반이며, 높은 수준의 데이터 유형과 초기적인 상태 및 엄격한 정적 타입 체크가 존재합니다. 이것의 디자인은 Forth, Scheme, ML and Cat에서 귀감을 얻게 되었습니다. 명령 세트의 구체적인 내용은 https://tezos.com/pages/tech.html, 2014. 에서 확인이 가능합니다. 해당 사이트에서는 완벽한 명령어 세트, 타입 시스템 및 언어의 의미를 제공하고 있습니다. 이 사이트는 간편하고 쉬운 매뉴얼이기 보다는 정확한 참조 매뉴얼을 제공하고 있습니다.

3.3.6. 사용료

지금까지의 이 시스템은 이더리움이 트랜잭션을 처리하는 방식과 매우 유사합니다. 하지만 테조스는 수수료를 처리하는 방식이 조금 다릅니다. 이더리움은 긴 프로그램들에 대해서 제멋대로 시간에 따른 선형적인 수수료 부분을 바꿉니다. 하지만, 이것은 한 광부가 거래를 검증할 보상을 제공하지만, 이 거래를 검증해야 될 다른 광부들에게도 그러한 동기, 즉 인센티브를 제공하진 못합니다. 또한 실제로, 대부분의 관심 가는 프로젝트들이 스마트 컨트랙트를 사용할 수 있는 시간은 매우 짧습니다. 따라서 우리는 프로그램을 실행할 수 있는 단계의 수를 엄격하게 부과함으로써 구조를 단순화시키게 됩니다.

이러한 하드 캡이 일부 프로그램에서 너무 빡빡하게 여겨진다면, 그들은 이것을 여러 단계로 나누어서 여러 트랜잭션을 이용해서 완전히 실행을 시키게 되면 됩니다. 또한 테조스는 수정될 수 있기에 향후에 캡을 바꾸거나 새로운 opcode로 조금 더 나은 선택안을 할 수 있을 것입니다.

계정이 허용하는 경우에는 변경을 요청하는 서명된 메시지를 발행하여 서명 키 또한 변경할 수 있습니다.

4. 결론

우리는 매력적인 시드 프로토콜을 구축했다고 느낍니다. 하지만, 테조스의 진정한 가치는 스테이크 홀더들이 그들이 가치 있다고 느껴지는 프로토콜을 만들어감에 있습니다.

---

백서 원문
번역 후기 - 테조스 한글 백서 번역을 무사히 끝마쳤습니다.

---

Steemit Token LAB 백서 번역 #1. 테조스

• Steemit KR에서 암호화폐 백서를 번역합니다. 첫번째 프로젝트로 테조스 백서를 한글로 번역하였습니다.
• 테조스에 관심이 많으신 @areyoucrazy 님께 번역을 의뢰하였으며, 빠르게 번역을 해주셨습니다. 앞으로 3번에 걸쳐 업로드할 계획입니다.
• 앞으로도 지속적으로 관심있는 암호화폐 백서의 번역 작업을 이어갈 계획입니다.
• 선 지급한 번역료 외에 본 글 저자보상 SBD의 30%는 번역가에게 전달되며, 50%는 다음 백서 번역을 위하여 적립합니다.

번역 저작권

• 이용시 출처 표시
• 비상업적 이용만 가능
• 변형 등 2차적 저작물 작성 가능

번역 후원자

skan
leesunmoo
ioc
arneb271828
bramd
ssm1810
musicholic
corn113
jyp
khaiyoui
jsg
kakaotalk
kwak
stellasjshin
kwonjs77
vingroup
ppomppu
inchonbitcoin
brent1042
segyepark
olorin
floridasnail
ibk
ediya
tabris
oldstone
blockchainnomad
happyberrysboy
aiyren
krexchange
jack8831
cheolwoo-kim
sonki999
sexyboy
chungjh
clarkgold
yoon
ksc
noctisk
get-cheaper
kimsungmin
louispark
changyoon
greenjuice
gotit
sonamoo
verygoodsurgeon
successtrainer
hyokhyok
beoped
yirgacheffe2shot
kingbit
doctorfriend
pitasa
jjangh1717
chunseungho
yangpankil27
woojumbs
uksama
deuksoo84
zet
cornerstone
tradingideas
lattecom
sinner264
coolzero
tigris
jungs
idas4you
sjchoi
tmkor
siritable
cine
loki80
solar-junely
backdm
vega321
sleepcat
banjjakism
steemtruth
smartbear
soon8013
iieeiieeii
jxwonah
sailingtohappy
sun510
koreaculture
ioe3
pyorinho
shinhancard
chipee
mawan1002
mooyeobpark
lonose
watermelon13
mattchoi
coffeenut
eversloth
jaywon
jsquare
d7795
hawoon
efsane
ohnamu
junhan57
arama
goodhello
wooklym
pediatrics
crawfish37
innople
hwantag
lcc3108
tjayhas
acceptkim
imnb
xiian
dmsqlc0303
lostmine27
roona1383
koreaminer
catharina
krgamer
room9
sismaru
thegreatgatsby
dongsuh
mandurah
joeuhw
partykim
hangeul
brianyang0912
sigizzang
rantertx
gilma
gidung
idencosmos
rainbowdash
ksheva1
jjangdol69
youngbinlee
skt1
soosoo
futurecurrency
dodge3507
brunch
thing-2
coldmonkey
heonbros
jjjjabe
dev1by0
dream-o
jisang
scylogo
jisui
aram04
jeongwooyu
gentlebot
danbain
cancerdoctor
lighthil
candyboy
holic7
simin
makefigure
wooyamum77
wabangcute
neojew
mastertri
minifam
bizventurer
happylazar
hukyong74
yeonhage
mrjang
hackerzizon
hygge
leemikyung
esccere
chunwu
seaturtle
yajirang
dhn0411
konan
comaiiii
chrisjeong
senseicat
lhy
yoonwonlim
hutchson
zorba
kopasi
rok-sivante
isi3
pkalra
luakiz
bluebottle
gaeteul
warofcraft
jinibh.house
ioioioioi
minseungchoi
bitcointravel
robrigo
steemarter
innovit
julianpark
actapeta
hyunaria
thewriting
tworld
lorem
creamer7
lsuny
yjc638
designkoi
steembest
naha
crowsaint
radiologist
steamsteem
bulsik
cubo
qkr1066
agar
yuky
blake.heo
capzzang
jsj1215
ojaber
stalk.yoon
kyju
dimon14
nickwalshblog
fordmogul
bue
tryword
hegel
hee4552
traveler.terry
biophil
dylanhobalart
gichan
amartinezque
da-dawn
forhappywomen
daydreams4rock
subijung01
fiat19
teeegs90
bonjovis
jay4u
kimegggg
energizer000
ssin
joopang2
rampant
drac59
judyhopps
nhj12311
gekko
kimminyoung
eth0619
ldsklee
emmaa
jeank
doctoryak
soyou.park
leeki7801
foruni73
toka
skuld2000
snowflake
luna33
freeyourmind
someonewhoisme
herokdj
hyoree
neoguri
joeparys
vandal
ghostcode
neonartist
card1001
foodflaneur
planet-power
illust
adelepazani
jameszenartist
meldesixym
aloha-mylife
randrade
anxin
coffeex
suin
willbeonceagain8
valueup
deanhass
junubia
procyon21
cryptoboii
jacobyu
thehoneybee
coldsiksu
vikaspoonia
elfrances185
steemitlsh
ivet
thomasfarley
tommycoin
learn2earn
nps0132
chic.hyun
dimens
stella12
formysons
eunyx
hkmoon
evesick
soul-factory
yyromkim
jd8578
jang-doctor
sonntag51
rkmrkm99
kimyh
lesto
munhwan
goodcontent4u
zionjohn
injoy
vommie
rahmanovic
limzua
asinayo
lovelyyeon
yong2daddy
piggypet
banguri
omani02
psitorn
cron
yahweh87
drgkim
tip2yo
agood
jonnyla08
go4d
apdls92
dianamun
chocolate1st
enturia
cryptodollar1
dongtube
koreart
mystory03
doctorbme
delphic
madamf
talkit
mysted
maikuraki
yellowrain
tcban
marskyung
qrwerq
millionfist
samuelhull
twohs