팩텀(Factom)의 프로토콜
안녕하세요, Seagull입니다. 이번 포스팅에서는 팩텀(Factom)이라는 코인에 대해 다뤄보도록 하겠습니다.
팩텀은 중요한 데이터(기업의 계약서나 서류 등)을 쉽게 블록체인상에 올리고, 필요할 때 쉽게 찾아서 증명을 할 수 있게 해 주는 코인입니다.
개인들보단 기업을 타겟으로 하며 기업용 클라이언트를 위한 데이터 보안 솔루션을 제공하려고 하죠. 비트코인에 직접 기업들이 데이터를 올리기엔 여러가지 문제점들이 있으니 이것을 최적화하여 더욱 쉽게 만든 것입니다.
과연 팩텀은 어떻게 이 아이디어를 구현하려고 하는 것일까요?
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가 '실패' 하는 경우 Federated Server 대신 Audit Server가 그 자리를 얻는다고 되어있는걸로 봐선 Federated Server가 되기 위한 '대기자'의 위치인 듯 합니다.
Follower Server는 오직 트랜잭션 처리 요청만 할 수 있습니다. 이 요청은 Federated Server로 넘어갑니다.
<팩텀 서버 관계도>
4. 팩텀 프로토콜에 데이터가 들어가는 과정
갈매기 씨가 Entry Credit을 이용해 지불을 하였습니다. 지불을 했다는 데이터는 Federated Server중 하나로 가서 이 서버가 지불을 승인하고, 승인한 사실을 네트워크의 모든 서버에 알립니다. 갈매기 씨가 지불한 금액이 승인이 완료되면 이제 갈매기 씨는 자신이 올리고자 하는 문서를 올릴 수 있습니다. 이것은 그냥 문서만 달랑 올라가는 것이 아니라 'Chain ID'라는 것과 함께 서버로 전송되는데요, Chain ID는 이 문서의 ‘분류, 그룹’을 식별하는 데이터라고 생각하면 될 것 같습니다. 추후에 이 문서를 다시 찾고 싶을 때 어느 칸에 분류를 해 놨는지를 말해주면 더 쉽게 찾을 수 있는 것이죠. 마치 도서관에 가면 대분류, 소분류별로 책에 번호가 붙어있는 것과 같습니다. 이 chainID는 갈매기 씨가 기록해줘야 할 Chain Name의 SHA256데이터입니다. 즉 갈매기 씨는 문서를 올릴 때 문서와 함께 Chain Name을 기록해줘야 합니다.
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들에게 알려 모든 서버가 분산원장을 최신변경사항으로 갱신하도록 합니다.
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를 조합한 목록이 있습니다.
<Factom Whitepaper - Directory Layer 구성>이 작업은 라운드당 총 10회 수행되는데, 10번째 Directory Block이 생성되면 각 Directory Block의 해시를 모아 Federated Server가 비트코인 블록체인에 추가할 최종 앵커로 해시합니다. 서버 중 하나가 무작위로 선택되어 비트코인 체인에 앵커 루트를 추가하고 전체 프로세스가 다시 시작됩니다.
<Factom Whitepaper - 전체적인 진행도>
이러한 식으로 데이터를 해싱에 해싱을 거듭하여 팩텀 프로토콜, 그리고 비트코인 프로토콜에 올린다면 상당한 비용을 절약하여 문서 증명을 할 수 있습니다.
다음 포스팅에선 특이한 팩텀의 코인 발행/소각 모델(Burning and Minting)과 가치평가에 대해 얘기해보려고 합니다.
처음 보면 팩텀 프로토콜이 상당히 난해할 수 있어서 최대한 이해를 돕기 위해 그림을 많이 넣었습니다.
제가 잘못 작성한 부분이 있을 수 있어 발견하신다면 댓글로 남겨주시면 감사하겠습니다!