openhash-bank.md

작성 중의 글입니다. 초고 마감 예정일 2018-02-25, 작성자: 팀 주피터

• 본문은 블록체인 1~3세대의 동작 메커니즘에 친숙한 독자를 상정합니다. 블록체인 기술에 익숙하지 않은 독자는 Coded Korea의 동영상 강의 - 프로그래머를 위한 블록체인 코딩를 참고하십시오.
• 표준화폐의 개발 취지는 왜 표준화폐인가?를 참조.
• 표준화폐에 관한 기술 요약은 표준화폐 기술 요약을 참조.
• 4세대 블록체인 Openhash에 관한 기술 요약은 Introduction to Openhash: A New Horizon을 참조. 

표준화폐는 주요하게 2013년 1월 오픈소스로 공개한 세 기술에 근거합니다.

• 공간 웹 기반의 화폐 시스템(SYSTEM AND METHOD FOR MONEY USING THE SPACE WEB)*,
• 공간 웹 기반의 시장 시스템(MARKET SYSTEM BASED ON THE SPACE WEB)
• 공간 웹 기반의 회계 방법 및 시스템(SYSTEM AND METHOD FOR ACCOUNTING BASED ON THE SPACE WEB)

특허청 특허검색, 특허실용신안 부문 검색어 공간웹*AP=[120120589655].

---

표준암호통화 및 글로벌 무인 은행 Whitepaper and Basecode

이 페이지는 Openhash 플랫폼 기반의 표준암호화폐(이하, 표준화폐)의 핵심 사상과 API를 기술한다.

오픈해시 암호화폐의 공식 명칭은 표준암호화폐 Standard Cryptocurrency이며, 약칭은 표준화폐, 별칭은 표준암호통화, 표준화폐이다.

• 표준화폐의 개발 취지 - Openhash 플랫폼을 이용한 표준암호통화와 글로벌 무인 은행.
• 표준화폐의 개요 - Openhash 표준암호통화의 기술 개요.

cycle.js framework는 두 가지 측면에서 사용된다.

• 표준화폐 플랫폼 자체가 cycle.js framework로 작성된다.
• 각 국가는 배정받은 표준화폐의 자국 내 사용과 관련하여, 자국의 관계 법령을 Smart Contracts의 형태로 적용할 수 있으며, Smart Contracts는 Cycle.js API로 작성하여야 한다. 이는 국가 간 Smart Contracts 모듈의 호환성을 높이고, 문법을 통일한다.
• 본 백서에 기술된 코드는 Functional Reactive Programming의 문법으로 작성된 Pseudo Code이다. Cycle.js는 Frontend Framework로 고안되었지만, 오픈해시 플랫폼은 이를 Backend Framework로 확장한다.
• 모든 통신과 기록은 HTTPS encryption를 전제한다.
• DB는 중앙의 백업 서버(Google Cloud Platform, Firestore)와 토렌트 방식의 Peer-to-Peer 분산 서버가 쌍으로 운영된다.
• 한국을 예로써, 표준화폐가 적용되는 과정을 기술한다.

---

플랫폼 초기화

main()을 호출하여 일정량의 표준화폐(Yip)를 생성하고, 각국의 GDP 규모에 비례하여 각국에 배정한 뒤, 표준화폐 플랫폼을 초기화한다.

main() {
 //Issue 20 trillion Yip.
 const baseMoney: Number = 2e+12;
 const baseYip = issueYip(baseMoney);
 
 //allocate Standard Cryptocurrency among 193 nations registered to UN according to the GDP of each nation.
 allocateYip(baseYip);

 //Initialize One Onnuri Server.
 initOnnuri();

 //Initialize 193 Supul Servers for 193 nations.
 initSupul();
 
 //Initialize 65,536 hierarchical Gruturki Servers per 1 Supul Server of each nation.
 initGruturki();
}

이하, 지불자를 Payer, 수취자를 Receiver, 출금 계좌를 Input, 입금 계좌를 Output이라 표현한다.

Openhash Core Openhash Core는 Open source(MIT)이며, 2020년까지 SCC - Standard Cryptocurrency Committee가 소스코드를 제어한다. 2021년부터, 관리그룹 없이 스스로 소스코드를 갱신하는 알고리즘이 적용된다.

API는 Cycle.js 프레임워크를 토대로 작성되었으며, 대부분의 프로그래머에게 익숙한 OOP(Object Oriented Programming) 방식이 아니라, FRP(Functional Reactive Programming) 방식으로 작성되고 있다. OSCR - Openhash Standard Cryptocurrency Repository에서 다운받을 수 있다.

1. 표준화폐와 참여자

표준화폐는 SCC - Standard Crytocurrency Committee 글로벌 표준화폐위원회가 규정하고, 각국 정부 NCC - National Cryptocurrency Committee 국가 표준화폐위원회가 제작 및 배포한다.

표준화폐의 단위는 1, 10, 100, 1000, 10,000, 100,000 … 등이며, 각각의 수량은 별도로 정한다.

1.1 표준화폐

비트코인 등 암호증표와 달리, 표준화폐는 장부가 아니라, IP 주소를 갖는 디지털 화폐이다.

IPv6 주소를 예로써, 16비트의 Subnet ID 중 4비트(16)에 화폐 단위를 할당하고, 발행된 화폐 디지털 지폐 각각의 고유한 ID를 Interface ID 64비트에 할당한다. 가령, 화폐단위 1은 0001, 10은 0010, 100은 0011 등이다. 따라서, 화폐단위는 1~10,000,000,000,000,000로 표현할 수 있다.

어느 한 화폐의 소유권은 후술하는 참여자들 간에 이전될 수 있으며, 화폐 발행 총량이 실시간 측정되므로, 위변조가 발생할 경우 즉각 탐지된다.

화폐의 소유권 이전 과정은 후술하는 Smart Contract에 의해 제어된다.

// Describe the features of monetary units.
type MoneyUnit = {

}

money(){
const moneyUnit: MoneyUnit;
const address: IPv6Address;
let ownerKey: Key;
let receiverKey: Key;
let smartContract:SmartContract;
}

//Describe the properties of owner object.
type Owner = {
}

표준화폐의 경우, 종래의 암호증표에 적용되던 거래 수수료가 없다.

1.2 기록

표준화폐는 블록이 없다. 각각의 거래는 화폐 그 자체와 거래자의 통장에 기록된다.

1.2.1 통장의 기록

아래 그림을 참조하여, 종전의 블록체인에서, Alice와 Bob 간에 거래는 하나의 Transaction 데이터로 다음 번 블록에 기록된다.

아래 그림을 참조하여, 표준화폐의 경우, Alice와 Bob 각각의 통장은 제각기 통장주의 거래만 기록하는 초소형 블록체인을 구성한다. 시장 참여자가 1억명이라면, 1억개의 초소형 블록체인이 구성된다. 주목할 점은 거래 당사자 각각의 통장에 기록된 최종 Hash가 새로운 Hash에 반영되는 점이다.

• Alice와 Bob 각각의 최종 거래가 Hash 101, Hash 102로 표현된 상태를 가정하여, 이 두 사람 간의 새로운 거래는 거래 명세의 형태로 작성되며, 새로운 Hash 200는 Hash 101, Hash 102를 포함한 데이터로 도출된다
• 거래 명세는 후술하는 장부 기록자에게 전달되고, 또한, 각각의 통장에서 분개된다(분개 과정은 이하에서 자세히 설명한다).
• 따라서, 거래 당사자 모두의 통장에 기록된 거래의 최종 Hash는 같다.
• 거래 당사자가 셋 이상인 경우에도, 동일한 하나의 Hash가 새로운 거래 기록의 Hash로 제각각의 통장에 기록된다.
• 각자의 통장은 그 자체로 하나의 작은 블록체인이며, 시장 참여자들은 상호 간의 거래에 의해 Hash 값이 상호 연동된다.
• 따라서, 어느 한 통장의 위변조는 해당 통장의 소유자가 관여하는 모든 거래 당사자의 통장에 기록된 Hash 값을 무효로 한다.

1.2.2 화폐의 기록

표준화폐의 송금 또는 소유권 이전은 거래 발생 시점에 최소한 세 곳에 기록된다. 보내는 이의 전자지갑 Gaji, 받는 이의 전자지갑 Gaji, 후술하는 각 계층별 서버, 그리고 이전되는 화폐의 IP 주소에 할당된 웹페이지이다.

그 중, IP 주소에 기록되는 내용을 상세히 기술한다.

디지털 지폐와 주화를 포함하는 모든 화폐는 예시한 IPv6 주소와 같은 고유한 IP 주소를 가지며, 해당 주소에 할당된 웹페이지는 해당 화폐의 단위, 발행국가, 현재 소유자, 과거 소유자 이력, 거래에 사용된 이력 등을 기록한다. 가령, 한국 정부가 10Yip짜리 표준화폐를 100,000개 발행한다면, 이들 화폐는 제각기 자신의 웹페이지에 소유권 이전 이력 등의 정보를 기록한다.

moneyHistory(ipAddress){
}

또한, 주목할 바는 기록될 데이터의 양이다. 블록체인의 경우, 거래마다 기록되는 데이터의 양이 상이하고, 양에 비례하여, 기록 수수료가 차등적으로 부과된다. 그러나, 표준화폐는 기록수수료가 없으며, Openhash 플랫폼의 각 계층별 서버나 Neighbor Nodes에 기록될 데이터의 양도 어떤 거래나 동일하다. 기록될 데이터는 둘 혹은 그 이상의 거래 당사자들의 잔액, 거래 이벤트에 할당된 Hash, 및 Timestamp이다.

recordTxn(transanction){
const amount: Number;
const timestamp: Timestamp;
transaction.payer.balance: Number;
transaction.receiver.balance: Number;
}

화폐에 기록되는 소유권 이전 정보는 해당 화폐의 새로운 소유주의 통장에 기록된 Hash 정보와 함께 기록된다. 가령, Alice가 Bob에 10 Yip을 지불하고, 원재료를 구매한 거래의 경우, 화폐 수취자는 Bob이다.

표준화폐의 경우, 발행된 화폐(디지털 지폐와 주화) 각각이 고유한 IP주소를 가지고, 특정 화폐의 IP 주소에 현재 소유자 정보가 표시되며, 특정 시장 참여자의 통장은 보유 화폐들을 향한 포인터(pointer)들을 기록한다.

아래 그림을 참조하여, Alice가 지불한 10 Yip의 IP 주소가 2001:0db8:85a3:0000:0000:8a2e:0370:7334, Bob의 통장에서 상기 거래의 Hash가 13CCt137Pd1q2TzSoVs2jLrSj2L545ercx라면, 이 IP 주소에 할당된 웹페이지에 소유자가 바뀔 때마다 새로운 Hash 값이 연속적으로 기록된다. 따라서, 화폐의 위변조는 시장 참여자 각각의 통장을 위변조해야 하고, 전세계 국가 중 절반 이상이 담합하지 않으면 불가능하다.

1.3 기록자의 계층 구조

표준화폐의 경우, 거래는 Gruturki 등의 장부 기록자에 의해 실시간으로 블록에 반영되며, 장부는 계층 구조로 운영된다.

• 최하단 블록체인은 시장 참여자 각각의 통장이다.
• 그 위에 그루터기 블록체인이 운영된다.
• 그 위에 수풀 블록체인이 운영된다.
• 그 위에 온누리 블록체인이 운영된다.

비트코인 등 암호증표의 경우, UTXO 메커니즘을 통해 아래 문제를 해결한다.

• 지불자가 지불 통장 Bank book을 소유하고 있다는 증거.
• 지불자 Bank book에 기록된 화폐들 중 어떤 것을 지출할 지 결정하는 과정.
• 수취자, 또는 소유권을 이전받은 새로운 소유자가 새로운 소유권을 주장할 근거.

표준화폐의 해결책은 블록체인 계층구조이다.

• 거래에 참여하는 당사자 각각의 최종 Hash가 포함된 거래 명세서를 작성한다.
• 당사자 모두가 서명한 뒤, 그 Hash를 그루터기 서버 또는 상위 서버에 전달된다.
• 서버는 전달받은 Hash를 Openhash에 추가한다.
• 거래에 참여한 모두가 각자의 Ledger를 후술하는 Neighbor Node와 각 계층별 서버로 전송함으로써, 거래가 기록된다.
• Gossip Protocol과 계층별 서버 알고리즘으로 표준화폐의 위변조를 방지한다.

money(){
const moneyUnit: MoneyUnit;
const address: IPv6Address;
let ownerKey: Key;
let receiverKey: Key;
let smartContract:SmartContract;
}

Digital key와 Digital Signature는 이하 13. Digital keys, Yip addresses, and digital signatures 에서 자세히 다룬다.

1.4 거래 수수료

비트코인의 거래 수수료(Transaction Fees)는 Sybil Attack을 방지하는 순기능이 있지만, 표준화폐는 거래 수수료가 없다. 대신, 각국의 세법에 의한 세금이 거래 수수료를 대신한다. 가령, 거래 금액에 10%의 부가세가 포함될 수 있다.

1.5 Locktime And Sequence Number

비트코인 거래는 비가역적(irreversible)이므로, 거래를 확정할 때까지 시간적 여유를 둘 필요가 있다. Locktime And Sequence Number은 시간적 여유를 제공한다. 그러나, 표준화폐는 종래의 상거래와 동일한 메커니즘으로 환불 규정과 분쟁중재위원회를 운용하고, 거래 당사자가 비가역적 거래와 가역적(reversible) 거래를 선택할 수 있으므로, 굳이 거래의 확정 시점을 유예할 필요가 없다.

1.6 Locking Script and Unlocking Script

비트코인의 Script는 매우 간단한 스크립트 언어이다(Forth-like reverse-polish notation stack-based execution language). 표준화폐의 Script는 JavaScript 및 그 파생 언어(TypeScript, Elm,CoffeeScript etc.)이다.

표준화폐에 부착되는 Locking 및 Unlocking Script는 이전 블록체인과 동일하다. 허가되지 않은 화폐 사용을 제약하는 Locking Script는 scriptPubKey( 또는 pubkey script 또는 witness script 또는 cryptographic puzzle)라 불리며, output에 부착된다. 이후, 이 output을 수취한 새로운 화폐 소유자가 해당 화폐를 지출하려면, 이전 소유자가 해당 화폐에 부착한 cryptographic puzzle을 풀어야 한다. 퍼즐을 풀면, 해당 화폐는 지출 가능한 상태로 전환한다. Unlocking Script(또는 Signature scripts 또는 scriptSig 또는 witness)는 퍼즐을 푸는 작업을 수행한다.

이전 블록체인과 달리, 표준화폐로 구매하는 자산에도 동일한 Locking 및 Unlocking 알고리즘이 적용된다. 가령, 표준화폐 100 Yip으로 제주도 한경면에 소재한 임야 100 평방미터를 구매했다면, 해당 임야의 소유자 변경 과정도 Locking 및 Unlocking 알고리즘에 의한다. 따라서, 별도의 등기부등본이나 법원 등기 절차가 필요하지 않다.

1.7 m-of-n pubkey script

이전 블록체인과 마찬가지로, n개의 pubkey들 중에서 m개의 동의가 있을 때, 지출할 수 있도록 제한을 가하는 Output 방식이다.

이전 블록체인과 달리, 표준화폐를 결제 수단으로하는 모든 거래는 m-of-n 거래이며, 모든 거래 당사자의 서명을 요구한다. 서명은 화폐 뿐 아니라, 화폐와 교환되는 재화와 서비스의 새로운 소유자가 그 소유권을 주장할 객관적 근거이다.

multiSig(){
}

1.8 Escrow And Arbitration

제 3 자의 개입을 통한 안전 거래 메커니즘이다. 가령, A와 B 간의 거래에 C를 개입할 수 있다. 블록체인과 표준화폐의 차이점은 전자가 사람을 제 3자로 지정하는데 비해, 후자는 AI(Artificial Intelligence) 모듈을 이용한다. AI 모듈의 상세는 후술한다.

safeTx(){ }

1.9 거래의 익명성

옛 블록체인의 경우, 모든 거래는 암호화되지 않은 상태로 블록에 기록되며, CoinJoin 메커니즘으로 익명 거래를 도모한다. 표준화폐의 경우, 모든 거래가 암호화되므로, 개인 정보를 노출하지 않기 위한 별도의 메커니즘이 필요하지 않다.

암호화된 거래 정보는 법과 규칙에 따른 권한있는 기관 또는 개인에게 제공된다. 법과 규칙은 시민의 집단적 의사에 의한다. 시민의 의사를 체계적으로 수집하는 알고리즘은 민주주의이다.

특정 기관이나 개인이 특정 정보를 열람할 법적 권한이 있는 지 여부는 법원 또는 AI 모듈에 의하면, 상세한 과정과 절차는 AI 항목에서 기술한다.

1.10 전자 지갑 Wallets

옛 블록체인의 경우, Public Key를 변조한 Coin Address로 돈을 받으며, Public-private key의 조합으로 지출을 승인한다. 표준화폐의 전자지갑은 은행 통장과 동일하며, 고유한 IP 주소를 갖는다. 개인 정보의 노출을 피하기 위해, IP 주소를 사전(dictionary)의 단어로 치환하여, 입금자 또는 결제자에게 제시할 수 있다.

통장은 보유 화폐 각각에 대한 포인터 변수(pointers)를 기록한다. 특정 디지털 화폐를 지출하면, 해당 화폐를 가리키는 포인터가 삭제된다. 어느 한 통장에서 어느 한 디지털 화폐를 향한 포인터가 삭제될 때, 반드시 해당 화폐에 대한 포인터를 기록한 새로운 통장이 나타난다. 디지털 화폐 각각은 고유한 IP 주소를 가지며, 해당 주소에 할당된 웹 페이지 혹은 웹 DB는 해당 화폐의 현재 소유자를 가리키는 포인터가 기록된다.

bankBook(){
}

1.11 Private Key

블록체인 1~3세대는 Random으로 숫자를 생성하여 Private Key를 구성한다.

표준화폐 플랫폼에서 Private Key는 아래 다섯 방법의 조합으로 생성할 수 있다.

• 지문
• 홍채
• 목소리
• 필기체 서명
• 아이디와 비밀번호

따라서, 암호증표와 달리, 표준화폐는 분실과 도난이 없다.

종래의 은행 시스템과 달리, 시장 참여자 각각의 Private Key를 저장한 서버가 없다는 점에 주목할 필요가 있다. 표준화폐 시스쳄에서 Private Key의 진위 여부는 종래의 블록체인과 동일한 알고리즘이 적용된다.

generatePrivateKey(){
}

1.12 지불 Payment 보다는 교환 Exchange

옛 블록체인과 마찬가지로, Transaction Protocol과 관련하여, X.509 certificates과 SSL encryption을 이용한다. 표준화폐의 특징은 QR 코드 대신에 색상 코드를 사용하는 점이다(### 8. 인증 항목에서 자세히 설명한다).

옛 블록체인과 달리, 표준화폐 플랫폼은 화폐의 흐름 뿐 아니라, 재화와 서비스의 흐름도 같은 비중으로 기록하는 점에 주목해야 한다. 따라서, 지불 매커니즘이 아니라, 교환 메커니즘이다. 옛 블록체인의 Payment보다 CoinJoin 메커니즘이 표준화폐의 거래에 더 가깝다.

거래(transaction)가 발생하면, 아래 정보가 포함된 명세서와 당사자들의 서명, 그리고 각 당사자의 통장에 기록된 최종 Hash를 하나의 데이터 뭉치로 하여, 그로부터 새로운 Hash를 도출한다. 새로운 Hash는 당사자 각각의 최종 Hash로 새로이 기록되며, 또한 Book keeper를 포함하는 peer-to-peer node들로 전파된다(Gossip Protocol).

데이터 뭉치는 다음 정보를 포함한다.

• 거래에 참여하는 당사자들 각각의 고유한 ID
• 각 당사자들이 제공하는 가치(재화, 서비스, 국적화폐, 표준화폐 등)
• 가치의 분할 또는 귀속 대상
• 당사자 각각의 서명
• 당사자 각각의 통장에 기록된 최종 Hash

1.12.1 화폐와 화폐의 교환

표준화폐와 국적통화(Fiat)의 교환이 대표적이다.

currencyExhange(){
}

1.12.2 화폐와 상품의 교환

통상적인 상거래이다.

eCommerce(){
}

1.12.3 상품과 상품의 교환

물물교환이다.

barter(){
}

1.13 Forex Risk

암호증표의 경우, 코인 가격 하락이 예상되면, 코인 보유자는 신속히 코인을 쓰려 할 것이고, 상품 판매자는 코인 결제를 꺼려할 것이다. 반대로, 가격 상승이 예상되면, 코인 보유자는 안쓸 것이다. 어떤 경우에도, 코인은 결제 수단으로써 역할하지 못한다.

그 외에도 옛 블록체인은 설계 상의 단점이 있다. 거래 상대방의 자금 흐름을 추적할 수 있고, Double Spending의 위험도 그 중 하나이다. 물론, 그에 대한 나름의 처방도 있다.

• Merge Avoidance: 자금 추적을 피하는 방법
• Last In, First Out (LIFO): Double Spending의 위험을 타인에게 전가
• First In, First Out (FIFO): Double Spending의 위험을 본인이 감수

표준화폐는 그 가치가 각국의 국적 통화에 연동되므로, 신속히 소비할 이유도, 쓰지 않을 이유도 없다. 그러나, 국적 통화들 간의 교환비 변동 위험, 혹은 환 위험(Forex Risk)이 새로이 이슈가 될 수 있다. 가령, 한국 원화와 표준통화 간의 교환비가 1,000:1로 고정된 상태를 가정하자. 외환 시장에서 원화의 가치가 상승하거나 하락할 때, 표준통화가 과대 평가(Over estimate)되거나 과소 평가(Under estimate)된다. 따라서, 각 국적 통화와 표준화폐 간의 교환비는 고정될 수 없다.

국적 통화와 표준통화 간의 교환비가 변동한다면, 각 주권 국가의 통화 정책(Monetary Policy)이 무의미해지는 문제가 발생한다. 표준통화와 국적통화 간의 교환비를 고정한다. 따라서, 표준통화 역시 발행국가의 국적을 가진다. 발행국가 외의 국가에서 표준통화를 사용할 때는 발행국가와 사용국가 간의 환율에 사용국가의 표준통화를 구매하여 사용하는 방식이 적용된다. 그러나, 환전이나 송금 수수료가 없다는 점이 기존의 국적 화폐 및 은행 시스템과 다르다.

특정 국가의 국적통화에 연동되지 않는 표준통화는 후술하는 **열매(Yeolmae)**로 제공된다. 열매는 다국적 기업의 주가와 마찬가지로, (1) 그 가치가 특정 국가의 국적통화에 연동되지 않고, (2) 가치 변화 또는 가격 변동이 상대적으로 크다. 열매는 12항에서 자세히 다룬다.

1.14 Operating Modes

Simplified Payment Verification (SPV)

1.15 전파 Propagation

새로운 참여자의 존재를 peer-to-peer 네트워크의 여타 참여자들에게 전파하는 방법으로 블록체인은 연결된 노드 node들 간에 새로운 정보를 전달하는 flooding 메커니즘을 이용한다. 이론적으로는 수 초 이내에 어느 한 노드의 정보가 네트워크에 참여하는 모든 노드로 전파되어야 하나, 현실적으로는 불가능하다. 가령, 세계 인구의 절반이 peer-to-peer 네트워크에 참여하는 경우를 상정하여, 어느 한 노드의 거래 정보가 수 초 내에 모든 노드에 전파되려면, 모든 노드가 모든 노드에 대한 정보를 획득해야 하며, 그러기 위해서는 모든 참여자의 스마트폰과 PC의 용량이 수백 테라바이트이고(Full-node clients), 모든 노드가 초당 수백 기가 바이트의 인터넷 대역폭을 가져야 하며, 평균 크기의 원자력 발전소 1,000개 이상의 전력을 소비해야 한다.

표준화폐 플랫폼은 후술하는 계층적 서버 알고리즘을 제시하는데, 어느 한 노드는 자신이 소속된 지역의 서버와 해당 지역의 neighbor nodes에 거래 정보를 전송하는 것으로 전파 과정이 종결된다. 전자는 IPv6 프로토콜, 후자는 Gossip Protocol에 의한다.

propogateTxn(txn: Transaction){
// Inform Gruturki server of the transaction.
Const gruturkiServer: IPv6Address;
httpRequest(gruturkiServer, txn);

// Gossip the transaction.
gossip(txn);
}

1. 16 참여자

화폐를 소유하거나, 그 소유권을 이전할 권한을 갖는 자연인과 법인이다.

지표면 상의 어느 한 지점은 하나의, 꼭 하나의 그루터기에 속하며, 어느 한 참여자는 하나의, 꼭 하나의 주소지 서버에 등록되고, 주소지 서버는 하나의, 꼭 하나의 그루터기를 대표한다.

자연인 또는 법인은 웹을 통해 표준화폐 플랫폼 SCP - Standard Cryptocurrency Platform에 가입한다. 플랫폼은 그/그녀의 동의를 얻은 후, 이름, 주소, 휴대폰 번호를 포함하는 개인정보를 획득한다. 참여자의 PC 또는 스마트폰에 설치되거나, WebApp의 형식으로 제공되는 전자지갑 가지 Gaji를 초기화한다.

• 개인 정보를 인출한 뒤, 암호화하여,
• 주소지 서버를 결정하고, 해당 서버의 DB에 참여자를 등록한다.

// Connect to the SCP website via a smartphone**.
// When a user touches Register Button

register() {
 //Obtain user permission
 const permission: Permission = askPermission();
 
 // Store personalData
 const personalData: PersonalData = obtainPersonalData(permission);
 
 // Register to Address Server DB and User DB
 register(personalData);
 
 // init Wallet, Gaji.
 const userGaji = initGaji(personalData)
 
 // install Gaji into the user smartphone or PC
 installGaji(userGaji)
}

거래가 발생하면, 두 거래 당사자의 주소지 그루터기가 일치할 경우, 해당 그루터기로 거래 정보를 전송한다. 아니라면, 수풀로 전송한다. 역시 아니라면, 온누리로 해당 정보를 전송한다.

// Send transaction data to Gruturky | Supul | Onnuri.
sendTxData(){
 
}

1.17 참여자 리스트

표준화폐 플랫폼은 국가가 관리하며, 국가는 시민이 제어한다. 이 플랫폼의 안정성은 민주주의에 기초하며, 민주주의는 시민의 집합적 의사 결정이다.

또한, 표준화폐 플랫폼은 계층적 서버와 분산 서버에 표준화폐 네트워크(이하, ‘네트워크’) 참여자의 리스트를 보유하는 점에서 Private 네트워크이며, 누구나 가입할 수 있다는 점에서 Public 네트워크이다.

참여자 중 자연인의 정체성은 얼굴, 지문, 성문, 홍채, 필체, 소속 국가에 등록된 성명, 그 신원이 확인된 휴대폰, 인터넷 전화 또는 유선 전화 번호, 그리고 XMPP 메신저 아이디로 표현된다. 법인의 경우, 공인된 법인 등록번호, 사업체 명칭과 법인 주소지 등으로 그 정체성을 표현한다.

• 베타 테스트 기간 동안, 스마트폰 번호로 네트워크에 가입할 수 있다.
• 한국 국적의 홍길동은 스마트폰 번호 010-1234-5678을 고유한 사용자 ID(82-10-1234-5678)로 할 수 있다.
• 가입 시점의 홍길동 주소지에 할당된 그루터기 서버가 홍길동의 주소지 서버가 된다.

registerNetwork(){
// Obtain the phone number and generate peculiar user id.
generateID();

// Obtain personal information.
obtainPersonalInfo();

// Determine Address server and register user id.
initAddressServer();
} 

2. 온누리(Onnuri)

표준화폐 플랫폼은 최상층 온누리부터 최하층 가지까지 계층적으로 조직되며, 각 계층은 자식 계층에 속하는 노드들 간의 거래를 기록한다. 즉, 온누리는 수풀들 간의 거래를, 수풀은 그루터기들 간의 거래를, 그루터기는 나무들 간의 거래를, 나무는 가지들 간의 거래를 기록한다. 다만, 그루터기들은 자체적인 계층 구조를 갖는다.

개개인의 금융 정보는 가지(= 전자 지갑 Wallets)에 기록되며, 가지는 그 중 일부 정보를 나무, 그루터기, 수풀 및 온누리에 전달한다. 상위 계층의 서버가 하위 계층 서버 또는 전자지갑 내부의 정보에 대해 접근할 수 있는 정도 또는 권한은 표준화폐 플랫폼을 운영하는 개별 주권 국가의 법규에 의한다.

개별 국가마다 하나씩 할당된 온누리 서버는 블록체인의 Miner와 같은 장부기록자이다. 193개의 수풀 서버를 생성하고, 각국에 하나씩 할당한다.

 // Generate 193 Supul servers and store them in Onnuri DB.
initOnnuri() {
 const supuls: List[] = generateSupuls();
 const onnuriDb = supuls;
}

 //Generate Supul Server on Google Cloud Platform
generateSupuls() {
}

최상위 계층 서버이자 거래 기록자인 온누리는 후술하는 어느 한 수풀에 속하는 참여자와 다른 한 수풀에 속하는 참여자 간의 거래를 기록한다. 가령, 한국에 주소지 서버를 둔 참여자가 일본에서 지출한다면, 온누리 모듈이 그를 기록한다.

• 온누리 서버는 국가별로 하나씩 할당되고, 상호 동기화(Synchronization)한다.
• 온누리 서버의 데이터를 위변조하려면, 87개 국가 이상이 담합해야 한다.
• 온누리 서버는 193개 국가들 간의 거래를 기록한다.
• 어느 한 국가를 대표하는 수풀의 지출은 다른 한 국가를 대표하는 수풀의 수입이므로, 온누리의 대차변은 항상 균형이다.
• Onnuri DB는 UN 가입 193개국 각각이 독자적으로 기록하며, 정기적으로 상호 비교한다.

// call if any part of a transaction belongs to another Supul.
onnuri(transaction) {
 // Balance of Onnuri **shall not** be changed.
 static onnuriBalance: double;
 
 const payer = transaction.payer;
 const receiver = transaction.receiver;
 const amount = transaction.amount;
 
 // Adjust the balances of Supuls which each traders belong to.
 payer.onnuri.credit -= transaction.amount;
 receiver.onnuri.debit += transaction.amount;
 
 // Check balance.
  checkBalance();
}

// Initialize Onnuri Finantial Statement
initOnnuriFS() {

};

3. 수풀(Supul)

하나의 국가 또는 주를 담당하는 수풀 서버는 후술하는 서로 다른 두 그루터기가 관여하는 거래를 기록하며, 대차변은 항상 균형 상태를 유지한다. 어느 한 수풀에서 다른 한 수풀로 자금이 이전되는 거래는 온누리 모듈이 처리하듯, 두 그루터기 간의 거래는 수풀 서버가 기록한다.

어느 한 수풀에 소속된 참여자의 계좌에서 다른 수풀에 소속된 참여자의 계좌로 송금되므로, 온누리 서버와 달리, 수풀 서버의 Balance는 끊임없이 변동한다. 마이너스를 기록한 수풀은 해당 국가의 자본수지 적자를, 플러스를 기록한 수풀은 흑자를 의미한다.

// call if any part of a transaction belongs to another Gruturki.

supul(){
 // Balance of Supul **shall be** changed.
 static supulBalance: double;
 
 const payer = transaction.payer;
 const receiver = transaction.receiver;
 const amount = transaction.amount;
 
 // Adjust the balances of Supuls which each traders belong to.
 payer.supul.credit -= transaction.amount;
 receiver.supul.debit += transaction.amount;
 
 // Confirm debit of Supul are same to credit of Supul.
 checkBalance();

};

// Initialize Supul Financial Statement
initSupulFS() {
};

어느 한 수풀 서버는 65,536개 이하의 Gruturki 서버를 생성하여, 시군구 또는 읍면동에 하나씩 할당한다.

// Generate less than 65,536 Gruturki Servers for the designated Supul.
generateGruturgi(nationalCode){
}

수풀 서버는 그루터기 서버들의 대차변 합계를 집산하며, 어느 한 그루터기의 흑자는 다른 한 그루터기의 적자이므로, 수풀 서버의 대차변 합계는 항상 균형을 이룬다.

// Check the balance of supul server.
supulBalance(gruturkiList);

4. 그루터기(Grutorki)

하나의 수풀은 최대 65,536개의 그루터기 서버를 관리하며, 일반적으로 하나의 그루터기는 특정 수풀이 관할하는 시군구 또는 읍면동에 할당된다. 그루터기 서버는 특정 그루터기에 속하는 두 참여자(Namu) 간의 거래를 기록하고, 둘 이상의 그루터기가 관여하는 거래는 상위 계층인 수풀 서버로 거래의 기록을 위임한다.

수풀 서버와 마찬가지로, 그루터기 서버의 Balance 역시 끊임없이 변동한다. 어느 한 그루터기에 속한 참여자의 계좌에서 다른 그루터기에 속한 참여자의 계좌로 입출금되는 거래가 끊임없이 발생하기 때문이다. 즉, 어느 한 그루터기의 흑자는 다른 한 그루터기의 적자이며, 다수의 그루터기들 간 흑자의 총합과 적자의 총합은 항상 일치한다. 그러한 Balance는 수풀 서버에서 파악된다.

// call if any part of a transaction belongs to another Namu.

gruturki(){
 // Balance of Gruturki **shall be** changed.
 static gruturkiBalance: double;
 
 const payer = transaction.payer;
 const receiver = transaction.receiver;
 const amount = transaction.amount;
 
 // Adjust the balances of Gruturki which each traders belong to.
 payer.gruturki.credit -= transaction.amount;
 receiver.gruturki.debit += transaction.amount;
 
 // Confirm debit of Gruturki are same to credit of Gruturki.
 checkBalance();

}

시군구 또는 읍면동 각각에 할당되는 그루터기는 해당 그루터기에 속하는 참여자들 간의 거래를 기록하고, 또한, XMPP 메신저 서버 기능을 겸한다.

// Initialize Gruturki server.
initGruturki() {
}

// Initialize Gruturki B/S
initGruturkiBS() {
};

그루터기 서버는 온누리 서버나 수풀 서버보다 많은 양의 정보를 저장하며, 정보의 종류는 크게 두 종류이다.

• 채팅
• 거래 정보

두 종류의 정보는 각기 다른 서버에 저장된다.

// Initialize Chat Server using Google Cloud Plaform, Firestore.
initChatServer(){
};

// Initialize Transaction Server using Google Cloud Plaform, Firestore.
initTxServer(){
};

5. 나무(Namu)

그루터기의 구성원(Member)인 나무 Namu는 가계나 기업을 포함하는 단체를 대표하며, 해당 단체의 구성원이 하나일 수 있다. 나무는 후술하는 가지들의 입출금을 통합하며, 어느 한 나무의 흑자는 다른 한 나무의 적자이고, 어느 한 그루터기에 속하는 나무들 전체의 흑자는 해당 그루터기에 속하는 나무들 전체의 적자와 그 크기가 같다. 즉, 그루터기는 나무들 간의 균형 Balance이 판단되는 지점이다.

namu(){ 
 const payer = transaction.payer;
 const receiver = transaction.receiver;
 const amount = transaction.amount;
 
 // Adjust the balances of Namu which each traders belong to.
 payer.namu.credit -= transaction.amount;
 receiver.namu.debit += transaction.amount;
 
 // Confirm debit of Namu are same to credit of Namu.
 checkBalance();

}

6. 가지(Gaji)

하나의 나무는 하나 이상의 가지로 구성되며, 가지는 블록체인의 전자지갑(Wallet)에 대응한다. 개별 참여자의 금융 정보는 Gaji에 기록되며, 그 중 일부 정보가 나무, 그루터기, 수풀 및 온누리에 전달된다.

• 나무는 둘 이상의 가지 Gaji들 간의 거래를 기록한다. 어느 한 나무에 소속된 가지가 하나라면, 나무가 기록할 바는 없다.
• 그루터기는 두 나무 간의 거래를 기록한다.
• 수풀은 두 그루터기 간의 거래를 기록한다.
• 온누리는 두 수풀 간의 거래를 기록한다.

txn(contract: Contract){ 
 
 // Adjust the balances of Namu which each traders belong to.
 payer.gaji.credit -= contract.amount;
 receiver.gaji.debit += contract.amount;
 
 // Confirm debit of Gaji are same to credit of Gaji.
 checkBalance();
}

7. 재무제표

모든 가지, 나무, 그루터기, 수풀, 및 온누리는 그 자체가 재무제표이다. 발생한 거래는 Ledger, Income Statement, Balance Sheet, Cash Flow Statement, Retained Earnings Statement 등에 순차적으로 기록된다.

ledger.incomeStatement.balanceSheet.cashFlow.retainedEarnings.subscribe();

ledger(contract: Contract){
}

incomeStatement(){
}

balanceSheet(){
}

cashFlow(){
}

retainedEarnings(){
}


type Contract = {
 const date: Date;
 const location: Location;
 const payer: Payer;
 const receiver: Receiver;
 const amount: Number;
 const product: Product;
 const delivery: Delivery;
 const txnCode: SmartContract;
}

한 편, 표준화폐 플랫폼의 회계 시스템은 종래의 복식부기에 블록체인 메커니즘을 적용한 것이다.

7.1 Ledger

모든 거래에 있어서, 발생 시점의 기록은 중립적이다. 가령, A가 B에게 100 Y을 지불하고, 원자재를 구매한다면, A와 B 각각의 장부는 다음과 같이 기록될 것이다.

A의 분개장			B의 분개장
원자재 100	현금 100		현금 100	원자재 100

표준화폐 플랫폼의 관점에서 거래는 특정 재화의 소유권을 상호 교환하는 것이다. 만약, 원자재와 현금에 고유한 URI가 있다면, 다음과 같이 표현될 수 있다. URI만으로 해당 재화의 종류, 화폐는 그 금액 단위까지 알 수 있다.

B의 URI | A의 URI

이러한 표기법의 가장 큰 장점은 두 회계 주체 A와 B가 동일한 기록 내용을 공유할 수 있는 점이다. 달리 표현하면, A와 B의 분개장은 같은 거래에 대해 같은 내용을 기록하고, 그에 이전 Hash를 추가하여, 데이터 뭉치를 만들고, 그로부터 새로운 Hash를 추출할 수 있다.

이전 Hash + B의 URI | A의 URI => 새로운 Hash

즉, 각자의 장부는 작은 블록체인을 구성하며, 거래 당사자들의 장부가 상호 연동되므로, 그 누구의 장부도 위변조가 불가능해 진다.

// Record Transaction onto the books of all participants.
recordTx(participants: Participant[]);

7.2 재무제표

참여자들이 상호 공유하는 기록을 토대로, 각자는 각자의 재무제표를 생성할 수 있다.

8. 잎(Yip)

Yip은 국적통화의 가치와 연동된다. 모든 주권 국가는 상호 독립적으로 Yip을 발행하고, 통화 정책을 시행한다. 어느 한 국가가 발행하는 표준화폐의 단위는 해당 국가의 국적통화의 단위와 동일하고, 교환비는 1:1이다.

표준화폐의 표기는 전통적인 국적통화 표기에 소문자 d(= digital)를 추가한다. 가령, 한화(KRW)의 표준화폐는 dKRW이다.

8.1 잎(Yip)의 발행

잎의 발행 주체는 SCC(Standard Cryptocurrency Committee)이며, 배포 주체는 각국의 중앙은행이다. 중앙은행은 1:1 비율로 국가가 발행한 국적 화폐(Fiat Money)와 Yip을 교환한다.

잎의 발행에서, 거래 주체는 중앙은행과 시장 참가자이다.

// The amount of Yip given by SCC to the designated nation let balanceOfYip;

yip(fiatMoney){ // Exchange Rate between Yip and Fiat Money const yipToFiatRate: Number;

exchangedYip = fiatMoney/yipToFiatRate;

// Record transaction txn(contract: Contract);

balanceOfYip -= exchangedYip; }

7.2 잎(Yip)의 사용

표준화폐는 국적화폐와 동일한 가치를 갖고, 동일한 메커니즘으로 사용될 수 있다. 다만, 위변조를 방지할 메커니즘은 Private Key와 Public Key이 조합이다. 거래는 둘 이상의 참여자들, 및 참여자 각각의 서명에 의해 체결된다. 감가상각과 같은 1인 거래 역시 둘 이상의 참여자가 존재한다. 가령, 감가상각의 거래 참여자는 자산의 소유주와 감가상각 규칙을 제정하는 기관이나 단체, 한국의 경우, 회계표준위원회이다.

서명은 Private Key로부터 생성되며, 서명된 거래는 거래 당사자들 각각의 장부에 기록된다.

서명된 거래 데이터로부터 도출한 고유한 Hash 값은 아래 장소에 기록된다.

• 해당 거래에서 교환된 재물과 화폐 각각의 고유한 IP 주소에 기록된다. 가령, A가 B에게 100 Yip을 지불했다면, 그러한 거래 정보를 포함하는 데이터 뭉치로부터 유도된 Hash 값이 거래에 사용된 100 Yip의 고유한 IP 주소에 기록된다.
• 해당 거래에 참여한 거래 당사자 각각의 통장에 기록된다.

거래에 사용된 화폐의 고유한 IP 주소에 새로운 소유자의 고유한 IP 주소가 기록된다. 가령, 앞의 예에서, 새로운 소유자인 B의 고유한 IP 주소는 이전 소유자인 A의 고유한 IP 주소에 이어서 해당 화폐의 고유한 IP 주소에 기록된다. 따라서, 특정 화폐는 발생 시점부터 현재 시점까지 해당 화폐를 소유했었던 모든 소유자에 대한 정보를 보유한다.

8. Private Key, 신원 인증과 거래 방식

표준화폐 플랫폼에서 개별 참여자의 Private Key는 다양한 방식으로 생성될 수 있다.

8.1 아이디와 비밀번호(p/w)

표준화폐 플랫폼의 경우, 스마트폰과 PC가 일반적인 은행의 종이 통장을 대신하므로, 전자지갑인 Gaji를 열기 위해서는 하드웨어 로그인이 필요하다. 다양한 스마트폰 제조사들이 패턴, 아이디와 비밀번호(P/W), 지문, 홍채문 등의 로그인 방법을 제공하며, 개별 참여자의 단말기에 설치된 Gaji의 보안 수준은 해당 참여자가 사용하는 하드웨어 자원의 제조사에 영향받게 된다.

따라서, SCC는 하드웨어 장치의 제약에서 벗어난 보편적인 신원 인증과 전자 서명 메커니즘을 제시한다.

개별 참여자는 아래 인증 방식을 하나 이상 조합하여, 특정 작업의 인증 절차로 지정할 수 있다. 예를 들어, 거래 금액이 100Yip 이하인 경우, 목소리 인증으로 본인 인증 절차를 종료하고, 그 이상인 경우 목소리 인증과 서명 인증을 모두 통과하도록 지정할 수 있다.

목소리(Voice)

사전에 참여자가 몇 개의 힌트 단어와 그 각각에 대응하는 해답 단어를 입력해 두어야 한다. 이후, 인증이 필요할 때, Gaji는 참여자에게 힌트 또는 질문 단어를 제시한 뒤, 해답 단어를 참여자의 목소리로 입력받아, 정답 여부와 성문(Voice-print)으로 그 신원을 인증한다.

voiceLock() {
 //Show hint or question word to user
 showHintWord();
 
 //Obtain answer via mike.
 voiceAnswer();
}

8.2 서명(Signature)

펜을 내장한 스마트폰이나 PC에 한하여, 서명으로 신원을 인증하는 방법이다. 마찬가지로, 사전에 참여자가 몇 개의 힌트 단어와 그 각각에 대응하는 해답 단어를 입력해 두어야 한다.

voiceLock() {
 //Show hint or question word to user
 showHintWord();
 
 //Obtain answer via touch panel of smartphone or other device.
 penAnswer();
}

8.3 색상 카드

간판이나 명함, 표지판과 같은 시각적 데이터로부터 참여자의 ID를 획득할 방법이다. 가령, '홍 길동'이라는 문자열은 9개의 자모로 구성되며, 각각의 자모에 16색 중 어느 하나를 할당할 때 가능한 조합은 16의 9승이다. 9개의 색상 코드를 합친 숫자열로부터 도출된 Hash가 참여자 홍 길동의 고유한 ID일 수 있다.

colorCode(){
//obtain alphabets from string.
obtainChar();

//obtain color from character.
obtainColor();

//obtain hash from color codes
hashFromColor();

}

8.4 홍채 Iris

홍채 무늬로 신원을 인증하는 방식이다. 일반적인 홍채 인식 메커니즘은 서버에 저장된 개개인의 홍채 정보와 새로이 입력된 홍채 정보의 비교를 통해 본인 여부를 판단하는데 반해, 표준화폐 플랫폼은 블록체인의 Private Key 생성 과정에 개개인의 홍채 문양을 이용한다. 따라서, 별도의 서버에 개인 정보를 보관할 필요가 없다.

// Read iris patterns of a user and authorize it.
authIris();

8.5 지문 Fingerprint

서명 인증과 전자펜의 이중 지문 인식 메커니즘을 결합하여 보안을 더욱 강화할 수 있다. 자세한 기술적 내용은 전자펜을 이용한 지문 인식 방법을 참조.

// Read fingerprints and authorize it.
authFingerprint();

9. 시장(Sijang)

참여자는 누구나 판매자 지위를 가지며, 판매하려는 상품을 시장에 등록할 수 있다. 상품명을 입력한 뒤, 같은 명칭으로 입력된 이전의 상품이 있는 지를 사전에서 검색하고, 있다면 해당 명칭의 상품들로부터 추출된 가장 보편적인 속성(standard property set)들로 오브젝트를 구성한다. 가령, ‘냉장고'를 판매하려고 한다면, 사전에서 ‘냉장고'를 검색하여, 그 속성을 도출할 수 있다.

| 제조사 | 제조일자 | 용량 | 전력소비량 | 디자인 | 배송 방식 |

판매자는 검색된 상품의 속성들 중에서 일부를 제외하거나, 새로운 속성을 추가할 수 있다. 판매하려는 상품이 사전에서 검색되지 않는다면, 그 판매자가 최초의 속성을 구성해야 한다.

sell(){
 //obtain product name
 productName();

 //search product name
 searchProduct();

 //search standard property set
 searchStdProperties();

//Add or remove properties();
composeProduct();

//List product.
listProduct();

}

시장에 등록된 상품의 구매, 결제, 배송와 세무 등은 단 한 번의 터치로 완료된다.

9.1 가역성

종래의 블록체인 기반 암호증표와 달리, 표준화폐의 거래는 가역적(reversible)이며, 수풀의 운영자인 국가나 주는 거래를 취소할 수 있다. 거래의 취소는 구매자와 판매자가 스왑된 역거래(Reversed Transaction)의 형태로 진행되며, 취소 여부는 각국 또는 각 주가 운영하는 거래중재위원회에 의한다.

9.2 고유 ID와 임시 ID

참여자 각각은 두 종류의 고유한 아이디를 갖는다.

첫째는 국가번호와 지역번호(또는 이동통신사업자 번호)를 포함하는 전화번호이다. 가령, 한국인 홍 길동의 휴대폰 번호가 010-1234-5678이라면, 그의 고유한 아이디는 82-10-1234-5678이며, 세계 전역에서 결코 고유한 아이디가 겹칠 수 없다.

둘째는 XMPP 메신저의 참여자 아이디이며, 역시 세계 전역에서 두 참여자가 같은 아이디를 사용할 수는 없다.

전화번호나 메신저 아이디를 노출하는 것은 바람직하지 않으므로, 무인은행은 입출금과 거래를 위한 별도의 가변적 임시 ID를 제공한다.

임시 ID가 작동하는 메커니즘은 다음과 같다. 특정 국가의 어휘가 수록된 사전(Dictionary)을 준비한다. 판매자 또는 자금 수취자(Receiver)의 표준화폐 수취 주소를 사전에서 무작위로 인출한 특정 단어에 매핑한다. 인출된 단어는 재차 인출이 불가한 잠금 상태로 전환한다. 해당 단어를 구매자 또는 자금 지불자(Payer)의 컴퓨터 장치로 전송한다. 입출금 거래가 완료되면, 해당 단어를 잠금 해지한다.

9.3 실시간 거래 기록

자신의 거래가 Publish될 때를 기다리는 블록체인과 달리, Openhash 플랫폼에서 거래는 즉각 기록되며, 실시간으로 종결(Settlement)된다.

가령, Alice가 Pizzahut에서 피자를 주문할 때,

• Alice는 자신의 최종 거래의 Hash가 포함된 디지털 주문서를 전달한다.
• Pizzahut은 Alice의 최종 거래 정보를 참조하여, 새로운 거래 명세서를 작성한다.
• Pizzahut은 명세서의 Hash를 Alice에게 전달한다.
• 양측은 각자의 Ledger에 이 거래를 기록하고, Hash of this transaction를 부착한다.
• Alice는 명시된 Amount를 Receipt Address로 송금한다.
• 양측은 이 거래를 전파한다(Gossip Protocol).

Components of the payment URL Hash of this transaction: "KzpHBzqzX2dK9UA9JFP3Di4oQAweBwqgm" Product: "Pizza" Amount: "15" Recipient: "Pizzahut" Receipt Address: "OADi4wdK9UzpH9JFP3BzqmoQAzX2eBwqg" Payer: "Alice", … Hash of Alice’s prior transaction: "HHBJFP3zqzX2A9Di4wedK9UzpBwqgQAmo" Hash of Pizzahut’s prior transaction: "MdK9UzpHBzqzX2BwqgmoQAA9JFP3Di4we"

9.4 즉각적 가치 실현 Instant Realization

종래의 시장 메커니즘에 의하면, 판매자가 상품이 판매되는 시점에 그 가치가 실현된다. 그러나, 표준화폐 플랫폼은 가치의 즉각 실현 메커니즘을 제공한다.

시장 모듈은 판매될 상품의 가치를 추정한 뒤, 추정 가치의 일부를 즉시 판매자의 계좌로 입금한다. 추후, 실제로 판매가 완성되는 시점에 선입금한 금액과 실현된 금액 간의 차액을 정산한다. 기술적 상세는 공간웹 기반의 시장 시스템을 참조할 것.

• 판매 상품의 가치를 추정하는 모듈은 DNN(Deep Neural Network)의 형태로 작성된다.
• 모든 상품은 먼저 플랫폼과 판매자 간에 이뤄지고, 이어서 플랫폼과 구매자 간에 이뤄지며, 최종적으로 두 거래의 차액을 정산한다.
• 이 과정은 DNN에 의해 지속적으로 학습되고, 따라서, 추정의 정확도가 향상된다.

10. 보안

블록체인의 강점은 거래 기록의 위변조가 극히 어려운 점이며, 4세대 블록체인 Openhash는 이전의 블록체인 기술보다 현저히 강력한 보안 시스템을 제시한다. 이 보안 시스템의 특징은 아래를 포함한다.

10.1 협정 세계시(Coordinated Universal Time) 또는 세계 원자시

국가 또는 주에 할당된 온누리 서버는 원자 시계를 운용하는 국가들 중에서 무작위로 일정 수의 국가를 선정하여, 자신의 전자 시계와 동기화하고, 수풀 서버는 온누리 서버에, 그루터기 서버는 수풀 서버에, 나무와 가지는 그루터기 서버에 동기화하는 방법으로 시침을 통일한다.

 onnuriSync.supulSync.gruturkiSynk.namuSync.gajiSync.subscribe();

10.2 결합 재무제표

가지의 재무제표는 소속된 나무의 재무제표로 통합되고, 이어서 그루터기, 수풀, 온누리 각각의 재무제표로 통합된다. 가령, 한국 제주도 한경면 판포중1길의 편의점에서 장부 위변조가 발생하면, 한경면의 그루터기 서버에서 탐지된다. 만약, 그루터기 서버에서 위변조가 발생하면, 한국을 관할하는 수풀 서버에서 그 사실이 탐지되며, 수풀 서버의 위변조는 세계 전체를 관할하는 온누리 서버에서 탐지된다. 온누리 서버를 위변조할 경우, 탐지할 방법이 없으나, 그러한 위변조는 원자 시계를 운용하는 국가들의 ½ 이상이 담합해야 한다.

ledger.cashFlowStatement.incomeStatement.balanceSheet.retainedEarning.subscribe()

ledger(contract:Contract){
 return ledgerItem;
}

cashFlow(ledgerItem) {
}

incomeStatement(ledgerItem: LedgerItem) {
 return incomeStatementItem;
}

balanceSheet() {
Return balanceSheetItem;
}

10.3 Proof of Credit

그루터기 서버가 통합하는 나무들의 절반이 담합하더라도, 오픈해시 플랫폼 상의 장부 위변조는 Proof of Credit로 인해 불가능하다.

만약 두 참여자가 동일한 거래를 달리 기록하면, 둘 중 크레디트 레벨이 높은 쪽의 기록이 우선한다. 각각의 가지, 나무, 그루터기 및 수풀은 고유한 Credit 레벨이 가지며, 레벨 계산은 보유금액, 거래량과 빈도 외에도, Credit Chain에 의해 결정된다. 가령, A가 B로부터 구매하고, B가 C로부터 구매한 경우, A의 Credit Level는 B의 그것에 영향을 미치고, B의 그것은 C의 레벨에 영향을 미친다. Credit Level은 주기적으로 계산된다. 일정 기간 동안 A의 레벨 변동은 A가 상품을 구매한 판매자들 각각의 Credit 레벨에 가중치를 부가한다. 간단히 표현하면, 나에게서 상품을 사간 이들이 번창하면, 그 이익이 나에게 돌아온다.

따라서, 보다 많은 Yip을 보유하고, 보다 자주 거래하며, 보다 신용도가 높은 이들과 거래한 멤버들의 Credit이 그렇지 않은 멤버들의 그것보다 높게 결정된다.

Proof of Credits은 차등적 민주주의와 유사하다. 통상의 민주주의가 1인 1표 원칙에 의거한다면, Proof of Credits이 적용된 표준화폐 플랫폼은 사회적 신망이 높은 이들이 그렇지 않은 이들보다 큰 의결권을 갖는 것이다.

credit(member: Member) {
 // determine weights of average Yip balance and of transactions.
 static amountWeight;
 static txnWeight;

 //determine moving average balance of Yip.
 averageYip();

 //determing moving average transaction amount and frequency.
 averageTxn();

 //obtain the change of credit levels of all members who bought products from this member.
 creditChangeOfBuyers();

 //calculate the credit level of this member.
 calculateCredit();

}

10.4 Free-In-Forced-Out

실명이 확인된 스마트폰 또는 일반 전화의 이용자는 누구나 멤버가 될 수 있다. 그러나, 규칙을 위반한 멤버는 플랫폼에서 퇴출된다.

규칙의 위반 정도는 Penalty Score로 기록된다.

penalty(member, reason){
	// Add penalty of reason to the penalty score of the member
	member.penaltyScore = reason.penalty;	
}

11. 은행

이전 세대의 블록체인이 중앙 은행의 기능을 담은 데 반해, 표준화폐는 시중 은행에서 인적 물적 자원을 제외한 **무인 은행(Autonomous Bank)**으로 기능한다.

11.1 예금

Yip의 보유 기간과 액수에 비례하여 지급될 이자는 3항의 자산 운용에서 나온다. 참여자는 자신의 보유 Yip을 투자와 예금으로 분할하여 지정하고, 투자를 자기 투자과 위탁 투자로, 위탁 투자는 그루터기 위탁 투자과 수풀 위탁 투자, 그리고 온누리 위탁 투자로 분할 지정한다.

따라서, 자산 운용의 주체는 자기, 그투터기, 수풀 및 온누리이다.

// Divide one’s Yip balance into three categories.
divideInvestBalance(member.balance) {

};

11.2 대출 및 신용카드

신용 한도는 대출 한도와 카드 한도를 포함한다. 한도는 유저의 Credit Level에 의하고, Credit Level은 전술한 메커니즘으로 결정된다. 구체적으로, Deep Neural Network에 유저의 활동 정보를 입력하여 산출한다. 활동 정보는 유저의 성별, 연령, 학력, 국적, 직업, 자산과 같은 전통적 지표 외에도 구매 특성, 판매 특성, 통화 특성과 같은 비전통적 지표들을 포함한다.

유저는 신용 한도 내에서 지불하며, 예금과 대출 중에서 지불 우선 순위를 결정할 수 있다. 통상, 소액은 예금 잔고에서 지불되며, 거액의 경우, 일정 비율로 대출을 포함함으로써, 예금 잔고를 일정 수준으로 유지할 수 있다.

dividePayBalance() {

}

11.3 자산 운용

수풀과 그루터기의 자산 운용은 정책적이며, 온누리의 그것은 시장적이다.

국가 권력을 대변하는 수풀은 자국민이 그루터기와 온누리에 위탁 투자할 금액에 일정한 한도를 강제할 수 있다. 그러나, 어느 한 국가가 자국민의 투자 활동에 과도한 제한을 가할 경우, 국가 신뢰도 손상이 불가피하므로, 자연스레 국가 권력의 행사 정도가 제어될 수 있다.

// Supul can limit the investing decisions made by her people
limitInvest() {
}

한편, 투자를 위탁받는 그루터기는 일반적으로 주소지 그루터기이며, 주소지 그루터기 이외에 특정 그루터기에 투자하는 것은 자기 투자에 의한다.

주소지 시민들로부터 투자를 위탁받은 그루터기 등은 자체 알고리즘으로 투자 활동을 수행하며, 그러한 알고리즘의 작성은 해당 그루터기에 소속된 시민들의 민주적 의사 결정에 의한다. 표준화폐는 민주주의 지향 암호통화이다.

// Gather democratic decisions
democracy(){

Return democracy;
};


gruturkiInvest(democracy: Democracy){

}

12. 열매(Yeolmea)와 증권

온누리에 위탁된 투자 자산은 주식과 채권을 포함하는 증권에 지출되며, 그 수익의 분배권을 갖는다. 분배권은 열매의 형식으로 지급되며, 열매의 총량은 온누리에 위탁된 투자 자산의 총액과 같다.

열매의 발행 총량은 위탁 자산의 양에 비례하여, 증가하거나 감소한다. 열매의 거래 수단은 Yip이며, 가격은 미래의 현금 흐름을 현가 상각한 금액을 기준으로 수요와 공급에 의해 조정된다.

tradeYeolmae(invest){

buy();

sell();
}

투자 모듈은 언제 어떤 증권을 구매할 지 결정하며, 전형적인 Deep Neural Network로 구현된다.

onnuriInvest(){
}

12.1 증권 평가

온누리 펀드가 구매하는 증권의 추정 가격은 주요하게 해당 증권을 발행한 자의 Credit Level에 의해 결정된다. Credit Level은 국가 위험, 산업 위험, 기업 위험을 적정 비율로 가중한 값이며, 그러한 적정 비율은 DNN으로 구현된다.

evaluateSecurity(){
}

12.2 증권 거래

시장에서 상품을 판매하는 모든 기업은 자신을 대표하는 주식과 채권을 판매할 수 있다. 구매자는 온누리, 수풀, 그루터기, 또는 가지이며, 여타 상품과 동일한 거래 규칙이 적용된다.

13. 디지털 키, 잎 주소, 및 디지털 서명, Yip addresses, and digital signatures

블록체인의 경우, 디지털 키(Digital keys) 등은 블록체인과 무관한 별도의 주제이며, Wallet 기술과 관련있다. 그러나, 표준화폐와 디지털 키는 불가분이며, 지갑(Wallet)이라는 용어 대신 통장(Bank Book)이라 부른다. Elliptic curve multiplication, Hash algorithm과 Base58Check은 블록체인과 표준화폐가 동일하다.

국가로부터 표준화폐를 구매하는 참여자는 Random으로 구성한 (256비트 또는 64 hexadecimal digits) Private key에 Elliptic curve multiplication을 적용하여, Public key를 만들고, 이어서 hash algorithm과 Base58Check으로 Bank Book Address를 만든다. Private key의 포맷은 Hes, WIF, WIF-compressed 등이며, 블록체인과 동일하다.

비트코인 Vanity Address와 달리, 표준화폐는 미리 준비된 어휘 사전에서 무작위로 인출한 어휘(Locked Vocabulary)에 생성된 Bank Book Address를 매핑하고, 입출금 거래가 종료되면, 해당 어휘를 재차 사전 속에 인입한다(Unlocked Vocabulary). 따라서, 수신자의 계좌 번호는 소나무, 파랑새와 같은 친근한 어휘로 표현된다.

generateBankBookAddress(){
}

Bitcoin Address와 달리, 은행 통장과 동일한 기능을 갖는 Bank Book을 사용하는 표준화폐의 계좌를 Bitcoin의 경우와 마찬가지로, 매 거래마다 바꿔 사용하는 이유를 궁금해할 수 있다. 개인 정보 보안 때문이다. 항상 동일한 계좌 번호를 이용한다면, 만약, 그루터기 서버의 DB가 해킹될 경우, 해당 그루터기를 주소지로 하는 모든 참여자들의 금융 거래 내역이 완전히 누출된다.

13.1 Private Key의 보관

블록체인의 경우, Private Key를 분실하면, 자신의 암호증표를 영구히 상실한다. 게다가 참여자가 각기 자신의 Private Key를 외울 수 있게 할 묘안은 없다.

표준화폐의 경우, 참여자 각각의 Private Key를 국가가 보관하며, 그 획득 방법과 절차는 오직 참여자들의 민주적 의사 결정에 의한다. 즉, 표준화폐는 민주주의에 의해 지탱되는 금융 체계이며, 한 편으로는, 민주주의를 구현할 기술적 방안이다.

privateKeyRules(){
};

getPrivateKey() {
};

updatePrivateKey(){
};

setPrivateKey(){
};

deletePrivateKey(){
};

14. Smart Contracts

Coded Korea

---

Copyright (C) <2017> <주피터> This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.0. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/