[가상화폐] 팩텀(Factom)의 프로토콜

안녕하세요, Seagull입니다. 이번 포스팅에서는 팩텀(Factom)이라는 코인에 대해 다뤄보도록 하겠습니다.



factom.png




팩텀은 중요한 데이터(기업의 계약서나 서류 등)을 쉽게 블록체인상에 올리고, 필요할 때 쉽게 찾아서 증명을 할 수 있게 해 주는 코인입니다.
개인들보단 기업을 타겟으로 하며 기업용 클라이언트를 위한 데이터 보안 솔루션을 제공하려고 하죠. 비트코인에 직접 기업들이 데이터를 올리기엔 여러가지 문제점들이 있으니 이것을 최적화하여 더욱 쉽게 만든 것입니다.
과연 팩텀은 어떻게 이 아이디어를 구현하려고 하는 것일까요?


1. 팩텀은 비트코인에 자신의 데이터를 올린다?


팩텀의 특이한 점은 비트코인에 자신의 데이터를 올린다는 것입니다. 이게 무슨 말이냐면 팩텀 프로토콜과 비트코인 프로토콜을 연결시켜 특정 시간대마다 자신의 데이터를 가공해 비트코인에 올리는 것이죠. 비트코인에 자신의 합의 결과를 올림으로써 얻는 효과는 당연히 보안성 강화입니다. 자신의 체인에 문제가 생기더라도 비트코인의 데이터와 비교해서 잘못된 데이터가 들어있다면 사용자는 데이터를 거부할 수 있게 되니까요.


2. 팩텀의 지불방식


팩텀 블록체인에 데이터를 입력하기 위해서, 사용자는 팩텀 프로토콜의 2차 토큰인 Entry Credit이란 것을 구매해야 합니다. 이 Entry Credit은 FCT(=Factoid, 팩텀의 코인입니다)를 Federated Server(뒤에 설명하겠습니다)가 설정한 환율에 따라 Entry Credit으로 변환하여 생성할 수 있습니다. 현재 각 Entry Credit은 0.001달러 정도 되고, 각 Entry Credit은 소유자에게 1KB의 데이터를 팩텀에 입력할 수 있게 권한을 부여합니다.

예를 들어, 갈매기 씨가 팩텀 프로토콜에 100KB정도 되는 문서를 올리고 싶고 현재 팩텀 가격이 10$라고 합시다. 그렇다면 팩텀 하나로 얻을 수 있는 Entry Credit은 10/0.001 = 10,000개이며 각각의 Entry Credit은 1KB의 데이터를 올릴 수 있게 하므로 100KB를 올리기 위해선 100개의 Entry Credit만 있으면 됩니다. 따라서 갈매기 씨는 팩텀 0.01개를 구매해 팩텀 프로토콜로 전송시킨 후 사용하면 된다는 것이죠.

각 Entry Credit은 양도가 불가능하고 처음 산 소유자에게 묶여있도록 코딩이 되어있습니다. 즉 Entry Credit 자체의 가격변동요인이나 도난이 없게 설계를 해 놨다는 것이죠.
또한 Entry Credit으로 변환된 FCT는 소각되어 영구히 제거됩니다.


3. 팩텀 프로토콜의 서버


팩텀은 네트워크에 세 가지의 그룹이 존재하는데, 이는 ‘Federated Server’와 ‘Audit Server’, 그리고’Follower Server’입니다. 이를 번역하면 각각 연합 서버, 감사 서버, 수행 서버 쯤 되겠네요.

Federated Server는 블록 생성에 관련된 일을 담당하여 팩텀 체인에 데이터를 쓰고 보상을 받습니다. 이들은 사용자가 전송한 데이터 항목을 검사하지 않고 바로 Entry Block으로 넣는데요, 그 이유는 팩텀 프로토콜이 특정 데이터 구조를 요구하는 것이 아니라 사용자가 자신의 데이터 구조를 스스로 정의할 수 있도록 했기 때문입니다. 비트코인과의 차이점이죠.

Audit Server는 Federated Server가 하는 일을 감시하게 됩니다. 체인에 데이터를 쓰지 못하고 보상도 없다고 합니다. 다만, 백서를 보니 Federated Server가N'실패' 하는 경우 Federated Server 대신 Audit Server가 그 자리를 얻는다고 되어있는걸로 봐선 Federated Server가 되기 위한N'대기자'의 위치인 듯 합니다.

Follower Server는 오직 트랜잭션 처리 요청만 할 수 있습니다. 이 요청은 Federated Server로 넘어갑니다.

FACTOM 서버 그림.png


https://www.factom.com/university/tracks/fundamentals/3-types-of-nodes
<팩텀 서버 관계도>




4. 팩텀 프로토콜에 데이터가 들어가는 과정


갈매기 씨가 Entry Credit을 이용해 지불을 하였습니다. 지불을 했다는 데이터는 Federated Server중 하나로 가서 이 서버가 지불을 승인하고, 승인한 사실을 네트워크의 모든 서버에 알립니다. 갈매기 씨가 지불한 금액이 승인이 완료되면 이제 갈매기 씨는 자신이 올리고자 하는 문서를 올릴 수 있습니다. 이것은 그냥 문서만 달랑 올라가는 것이 아니라N'Chain ID'라는 것과 함께 서버로 전송되는데요, Chain ID는 이 문서의 ‘분류, 그룹’을 식별하는 데이터라고 생각하면 될 것 같습니다. 추후에 이 문서를 다시 찾고 싶을 때 어느 칸에 분류를 해 놨는지를 말해주면 더 쉽게 찾을 수 있는 것이죠. 마치 도서관에 가면 대분류, 소분류별로 책에 번호가 붙어있는 것과 같습니다. 이 chainID는 갈매기 씨가 기록해줘야 할 Chain Name의 SHA256데이터입니다. 즉 갈매기 씨는 문서를 올릴 때 문서와 함께 Chain Name을 기록해줘야 합니다.

factom-1.png
https://github.com/FactomProject/FactomDocs/blob/master/factomDataStructureDetails.md
<Entry의 구조>


참고로, 팩텀의 최대 지원 용량은 10KiB이기 때문에 갈매기 씨의 100kB데이터를 올리기 위해선 10번을 나눠서 올려야 합니다.

이렇게 문서와 Chain ID로 구성된 정보(Entry 라고 부릅니다)를 모든 서버가 받게 되면 Federated Server중 하나가 이 항목을 Entry Block에 추가합니다. Entry Block에는 여러 개의 Entry가 들어갈 수 있습니다. 그리고 이것을 다른 Federated Server들에게 알려 모든 서버가 분산원장을 최신변경사항으로 갱신하도록 합니다.

FactomEntryBlocks.JPG
https://github.com/FactomProject/FactomDocs/blob/master/whitepaper.md
<Factom Whitepaper - Entry Block 생성과정>




데이터를 해싱해서 올릴 수도 있고, 데이터 그대로를 올릴 수도 있습니다.

60초가 지날 때마다 모든 서버는 분산원장의 상태를 확인하고 서버의 Entry Block들을 Directory Block으로 모읍니다. Directory Layer는 Factom 시스템의 첫 계층 구조로, 여기엔 Chain ID와 해당 Chain ID에 대한 데이터가 들어있는 Entry Block의 Merkle root를 조합한 목록이 있습니다.

factomDirectoryLayer.JPG<Factom Whitepaper - Directory Layer 구성>




이 작업은 라운드당 총 10회 수행되는데, 10번째 Directory Block이 생성되면 각 Directory Block의 해시를 모아 Federated Server가 비트코인 블록체인에 추가할 최종 앵커로 해시합니다. 서버 중 하나가 무작위로 선택되어 비트코인 체인에 앵커 루트를 추가하고 전체 프로세스가 다시 시작됩니다.

completeFactomSystem.JPG
<Factom Whitepaper - 전체적인 진행도>


이러한 식으로 데이터를 해싱에 해싱을 거듭하여 팩텀 프로토콜, 그리고 비트코인 프로토콜에 올린다면 상당한 비용을 절약하여 문서 증명을 할 수 있습니다.



다음 포스팅에선 특이한 팩텀의 코인 발행/소각 모델(Burning and Minting)과 가치평가에 대해 얘기해보려고 합니다.
처음 보면 팩텀 프로토콜이 상당히 난해할 수 있어서 최대한 이해를 돕기 위해 그림을 많이 넣었습니다.
제가 잘못 작성한 부분이 있을 수 있어 발견하신다면 댓글로 남겨주시면 감사하겠습니다!

0
0
이 글을 페이스북으로 퍼가기 이 글을 트위터로 퍼가기 이 글을 카카오스토리로 퍼가기 이 글을 밴드로 퍼가기

블록체인 기술

번호 제목 글쓴이 날짜 조회수
공지 축 Work4Block 사이트 오픈 icon Work4Block 04-12 11,934
178 정보 KEEP!T Column: 블록체인 진영 시리즈(1) 제도권의 시도들 icon Work4Block 04-07 252
177 정보 KEEP!T Column: 구글 이후의 시대 - 조지 길더 icon Work4Block 03-15 283
176 정보 KEEP!T promotion: 광고에 블록체인의 핵심적 가치를 붙이면 생기는 일 icon Work4Block 03-07 297
175 정보 [인터체인 시리즈 I]코스모스 네트워크 I - 데이터 상호운용 방법과 텐더민트 합의 알고리듬 icon Work4Block 01-25 479
174 가상화폐 (코인비평) 라인 링크(Link)의 BTC 보상정책과 봉이 김선달 icon Work4Block 01-15 387
173 정보 KEEP!T History: 블록체인史 (최종) 블록체인의 새 패러다임을 제시한 이더리움 icon Work4Block 01-10 320
172 가상화폐 [eosDAC] 크리머 : 커스토디안 출마 선언 및 당선 공약 + eosDAC의 가치 상승 전략 icon Work4Block 01-02 315
171 가상화폐 (코인비평) 퍼블리토(Publyto)....스팀에 필요한 것이 이런 것이 아니었을까? icon Work4Block 01-02 315
170 가상화폐 [EOS는 도태될 것인가? 도약할 것인가?] 1편 : 기존 기업 블록체인(댑) vs EOS 블록체인(댑) icon Work4Block 12-26 339
169 가상화폐 (코인비평) 스팀(steem)의 진정한 호재 ; 구글 애드센스 도입 icon Work4Block 12-13 310
168 가상화폐 [EOS] 댄라리머 : 열심히 보단 똑똑하게 일해라. (CPU를 위한 효율적인 컨트랙트 개발)] (번역)) icon Work4Block 12-13 325
167 가상화폐 KEEP!T column: 하이퍼레저 패브릭(Hyperledger Fabric)의 거래 흐름 icon Work4Block 12-13 459
166 가상화폐 [번역+사견] 개발자들이 EOS를 사용해야 하는 이유 5가지. + 개발자 FAQ icon Work4Block 12-11 398
165 가상화폐 [CODEOS] 새롭게 배포된 EOSIO v1.5.0을 소개합니다. icon Work4Block 12-10 372
164 정보 블록체인은 살아날수 있는가 -ㅅ- icon Work4Block 12-10 314
163 정보 KEEP!T Column: UN SDG와 블록체인 icon Work4Block 12-06 355
162 가상화폐 EOS Snapshot 기능 소개 icon Work4Block 11-27 412
161 정보 KEEP!T column: 두나무의 블록체인 개발 플랫폼, 루니버스 icon Work4Block 11-17 427
160 정보 KEEP!T History: 스테이블 코인은 변동성에 답이 될 수 있을까. icon Work4Block 11-11 405
159 가상화폐 이오스는 왜 도박앱 투성일까 icon Work4Block 10-29 523