2장 비트코인의 작동원리




거래, 블록, 채굴, 블록체인


기존의 은행 업무 및 지불 체계와 달리 비트코인 시스템은 분산된 신뢰 네트워크를 기반으로 하고있다. 신뢰할 수 있는 중앙 통제 기관 대신 시스템 내의 다른 여러 참가자들의 상호작용을 통해 새롱누 속성이 생기면서 신뢰가 쌓이게 된다.


2장에서는 비트코인 시스템 내에서 진행되는 거래 과정에서 상위 단계이 있는 비트코인을 추적해서 거래 한 건이 분산화된 합의(Distributed consensus)라는 비트코인 메커니즘에 의해 '신뢰'를 얻고 승인을 받은 후 거래내역 전부가 담긴 분산 장부인 블록체인에 최종적으로 기록되는 과정을 살펴볼 것이다.


각 예시는 하나의 지갑에서 다른 지갑으로 송금 시 사용자들(Joe, Alice, Bob) 간의 상호 작용을 시뮬레이션하는 비트코인 네트워크 상에서 발생한 실제 거래를 기반으로 하고 있다.


블록탐색기는 비트코인 검색 엔진 역하을 하는 웹 어플리케이션으로, 이 서비스를 통해 비트코인 주소, 거래내역, 블록 등을 찾아볼 수 있고 이들 간의 관계 및 흐름을 볼 수 있다.


- 블록체인 인포(Blockchain info)

- 비트코인 블록 익스플로러(Bitcoin Block Explorer)

- 인사이트(insight)

- 블록아르 블록리더(blockr Block Reader)




비트코인 개요




그림에 나와있는 개괄 도표에서는 비트코인의 시스템의 구성 요소로 키가 들어있는 지갑을 보유한 사용자들, 네트워크에 전송되는 거래들, 거래내역 전부를 담고있는 권위 있는 장부인 동의 블록체인을(경쟁적 계산을 통해) 생산해 내는 채굴자들을 들 수 있다.




커피 한잔 구매하기


앨리스의 지갑에 0.1BTC가 송금되었다. 앨리스는 비트코인으로 첫 소매거래를 하기 위해 밥의 가게에서 커피 한 잔을 구매할 계획이다. 이는 판매시점 정보관리(POS) 시스템에 비트코인 옵션을 추가하면서 가능해졌다. POS 시스템은 달러로 나와있는 총 주문 가격을 일반적인 시세에 따라 비트코인으로 전환한 후 두가지 통화 단위에 대한 가격을 보여준다. 물론 이 거래에 대한 지불 요청(Payment request)이 들어있는 QR코드도 보여준다.


Total :

$ 1.50 USD

0.015 BTC


이 지불 요청 QR코드는 다음 URL을 인코딩한 것으로, 이는 BIP0021에 나와있다.


bitcoin:1GdK9UzpHBzqzX2A9JFP3Di4weBwqgmoQA?
amount=0.015&
label=Bob%27s%20Cafe&
message=Purchase%20at%20Bob%27s%20Cafe

Components of the URL

A bitcoin address: "1GdK9UzpHBzqzX2A9JFP3Di4weBwqgmoQA"
The payment amount: "0.015"
A label for the recipient address: "Bob's Cafe"
A description for the payment: "Purchase at Bob's Cafe"

송금할 비트코인의 목적지 주소만 담겨있는 QR코드와 달리 지불요청 QR 코드로 인코딩된 URL로서 목적지 주소, 지불 금액, 'Bob's Cafe등의 지불과 관련된 기본 내용을 담고있다. 지불요청을 통해 대금을 지불하는데 사용되는 정보를 미리 넣어 둘 수 있고, 동시에 사용자가 읽을 수 잇는 설명도 제공한다. 




비트코인 거래


간단하게 설명하자면 거래는 비트코인을 많이 보유한 소유주가 비트코인 일부를 다른 사람에게 전송하는 것을 승인한다고 네트워크에 이야기해 주는 것과 같다. 소유권의 사슬 속에서 비트코인의 새로운 소유주는 또 다른 소유주에게로 비트코인이 전송되는 것을 승인하는 다른 거래를 만드는 과정을 반복함으로써 매수한 비트코인을 소비할 수 있다.


각 거래는 하나이상의 '입력 값(Input)' 즉 비트코인 계좌에서 빠져나가는 차변과, 거래의 또다른 구성요소로서 하나이상의 '출력값(Output)' 즉 비트코인 계좌로 들어오는 대변으로 구성된다. 입력값과 출력값의 합계가 반드시 동일할 필요는 없다. 대신 출력값의 총합은 입력값의 총합보다 약간 작아야하며, 이 차이 값은 거래속에 포함된 '거래 수수료'가 된다.


거래 수수료란 공개장부에 거래를 포함시킨 채굴자가 수거하는 소액의 지불금이다. 비트코인 거래는 그림에서 보는 바와 같이 복식부기장부의 항목과 유사하다.


 또한 송금되는 비트코인의 금액(입력값) 각각에 대한 소유권을 소유주의 디지털 서명을 통해 증명하는 과정이 거래에 포함되며 누구든지 독립적으로 거래를 검증할 수 있다. '소비(Spending)'라 함은 이전 거래에서 송금되었던 돈이 비트코인 주소에 의해 확인된 새로운 소유주에게로 전송되는 거래에 서명을 함으로써 이루어지는 작업을 말한다.



 거래를 통해 거래 입력값에서 거래 출력값으로 가치가 이동한다. 입력값은 비트코인의 가치가 발생하는 지점으로, 주로 이전 거래의 출력값이다. 거래 출력값은 키를 이용해서 새로운 소유주에게 비트코인의 가치를 넘겨준다. 


 예상지출(Encumbrance)이라고 불리는 목적지는 향후 거래에서 나온 출력값을 새로운 거래에서 입력값으로 사용될 수 있다. 한 거래에서 나온 출력값은새로운 거래에서 입력값으로 사용될 수 있다. 이와 같이 소유권 사슬을 생성함으로써 가치가 비트코인 주소들 간을 이동하게 된다.


(한 거래의 출력값이 새로운 거래의 입력값이 되는 거래체인)



일반적인 거래 유형


가장 흔흐게 볼 수 있는 거래 유형은 하나의 주소에서 다른 주소로 단일 거래가 이루어 지는 형태이다. 이 경우 종종 원 소유주에게 돌려줘야 하는 '잔액'이 존재하며, 이때 하나의 입력값과 두 개의 출력값이 발생한다.


(가장 일반적인 트랜잭션)




또 다른 일반 유형으로는 여러 개의 입력값을 하나의 출력값으로 합치는 거래다. 이 형태는 실제로 동전과 단위가 작은 지폐가 많이 있는 경우 큰 단위의 지폐 한장으로 교환하는 행위와 동일하다. 지불 과정에서 잔액으로 받은 작은 단위의 금액을 정리하기 위해 지갑 어플리케이션에서 때때로 이 유형의 거래가 시행되기도 한다.


(돈을 합산하는 거래)



마지막으로, 비트코인 장부에서 종종 나타나는 일반적인 거래 유형은 하나의 입력값을 여러 명의 수신인에게 줄 수 있는 여러 개의 출력값으로 배분하는 형태다. 이 거래 유형은 기업체에서 다수의 직원들에게 급여를 지불하는 등 돈을 분배해야 할 경우에 사용된다.





거래의 구성


앨리스의 지갑 어플리케이션에는 앨리스의 명세서대로 거래를 진행하기 위해 적절한 입력값과 출력값을 선택하는데 필요한 모든 논리(logic)가 들어잇다. 앨리스가 해야할 일은 송금 목적지와 금액을 명기하는 일 뿐이다. 나머지는 앨리스가 자세한 사항을 지켜보고 있지 않아도 지갑 어플리케이션 내에서 진행된다. 더욱 중요한 사항은 완전히 오프라인 상태일 때도 지갑 어플리케이션을 통해 거래가 진행될 수 있다는 점이다. 마치 집에서 수표를 먼저 발행하고 나중에 봉투에 넣어 은행으로 우편 발송하는 것과 마찬가지로, 비트코인 거래도 굳이 비트코인 네트워크가 온라인에 접속해 있을 때 진행해서 서명할 필요는 없다. 단지 거래가 실행되어야 할 때 네트워크로 전송하기만 하면 된다.




올바른 입력값 얻기


우선 앨리스의 지갑 어플리케이션에서 밥에게 전송하기를 원하는 금액을 지불할 수 있도록 알맞은 입력값을 찾아야 할 것이다. 지갑 어플리케이션 대부분은 지갑 소유주가 보유한 키로 잠겨있는(지출이 예상되는) 'Unspent Transaction Output'에 대한 소용량의 데이터베이스를 보유하고 있다. 따라서 앨리스의 지갑에는 현금과 비트코인을 교환했던 조와의 거래에서 생성된 거래 출력값 복사본이 포함되어 있을 것이다.


풀 클라이언트(full client)를 사용하는 비트코인 지갑 어플리케이션의 경우, 블록체인상에 있는 모든 거래에서 실제로 발생한 UTXO의 복사본을 가지고 있다. 덕분에 지갑에서 거래 입력값을 생성할 수 있을 뿐만 아니라 정확한 입력값을 가지고 향후 거래를 신속하게 검증할 수 있다.


대부분의 사용자 지급에서는 사용자 본인의 UTXO만 추적하는 '라이트웨이트' 클라이언트를 가동한다.


지갑 어플리케이션에 소비되지 않은 거래 출력값 복사본이 보관되어 있지 않은 경우, 다른 제공자들에 의해 사용가능한 다양한 API를 이용하고 있는 풀인덱스 노드(full-index node)에 요청해서 해당 정보를 검색해달라고 비트코인 네트워크에 요구할 수 있다. 



(앨리스 비트코인 주소의 UTXO 전부를 조사)

$ curl https://blockchain.info/unspent?active=1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK

위의 예시는 RESTful API 요청으로, 특정 URL에 대한 HTTP GET 명령으로 작업을 진행한다. 이 URL의 경우 특정 비트코인 주소가 보유하고 있는 소비되지 않은 거래 출력값 전부를 돌려보내 주기 때문에 어플리케이션에서 소비를 위해 필요한 거래 입력값을 생성하도록 필요한 정보를 제공해 줄 수 있다. 우리는 응답을 받기 위해 단순 명령행인 HTTP 클라이언트 cURL을 사용한다.



(검색결과)

{

	"unspent_outputs":[

		{
			"tx_hash":"186f9f998a5...2836dd734d2804fe65fa35779",
			"tx_index":104810202,
			"tx_output_n": 0,
			"script":"76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
			"value": 10000000,
			"value_hex": "00989680",
			"confirmations":0
		}

	]
}



예시에 나와있는 결과를 통해 앨리스의 주소인 1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK가 소유권을 가지는 출력값 중에 UTXO가 한개 있다는 사실을 알 수 있다. 이 검색 결과에는 해당 거래에 대한 참조가 포함되며, UTXO가 들어있고 금액(1000만 사토시, 0.1 BTC)이 들어있다. 이 정보를 가지고 앨리스의 지갑 어플리케이션은 해당 가치를 새로운 소유주의 주소로 전송하기 위한 거래를 진행할 수 있다.




출력값 생성하기


 거래 출력값은 해당 가치에 대한 예상 지출을 생성하는 스크립트의 형태로 만들어지며 스크립트에 대한 솔루션이 제공되는 경우에만 사용할 수 있다. 쉽게 말하면 앨리스의 거래 출력값에는 '이 출력값은 밥의 공개키에 대응하는 키를 이용해 서명을 하는 누구에게나 지불 가능하다' 라는 의미가 담겨있는 스크립트가 포함되어 있을 것이다. 


 밥의 해당 비트코인 주소에 대응하는 키를 가진 지갑을 가진 사람은 밥 뿐이기 때문에 밥의 지갑에서만 출력값을 가치로 사용할 수 있는 서명을 제공할 수 있다. 따라서 앨리스는 밥의 서명을 요구하는 출력값에 대한 '지출을 예상할' 수 있다.


이 거래에는 출력값이 하나 더 존재할 것이다. 왜냐하면 앨리스의 돈은 0.1BTC에 대한 출력값의 형태인데 커피 한잔가격은 0.015 BTC이기 때문이다. 따라서 앨리스는 0.085 BTC를 돌려받아야 한다. 앨리스의 잔액에 대한 지불은 밥에대한 지불과 동일한 거래 내에서 이루어지며 앨리스의 지갑에서 생성된다.


기본적으로 앨리스의 지갑에서는 그녀가 보유한 돈이 두가지 거래로 쪼개진다. 하나는 밥에게 송금하는 거래이고 하나는 그녀가 잔액을 수신하는 거래다.




이 거래에 명시되어 있지 않고, 입력값과 출력값 간 차이로 알 수 있게 되어 있다. 0.085를 잔액으로 받는 것 대신에 두번째 출력값으로 0.0845만 생성한다면 0.0005BTC(0.5 밀리코인)가 남게된다.


결과적으로 산출되는 입력값과 출력값 간의 차이값이 거래 수수료(Transaction fee)가 되는데, 이는 채굴자들이 해당 거래를 블록에 포함시키고 블록체인 장부에 올리는 데 대한 수수료 명목이다.




거래내역을 장부에 추가하기


 앨리스의 지갑 어플리케이션에서 생성된 거래는 258바이트 크기로 돈의 소유권을 확인하고 새로운 소유주를 배정하는 데 필요한 모든 정보를 포함하고 있다. 한 건의 거래가 어떻게 새로운 블록의 부분이 되며 그 블록이 어떻게 '채굴' 되는지에 대해 살펴볼 것이다. 그리고 계속해서 추가되는 상황에서 새로운 블록이 블록체인에 추가된 후 어떻게 신뢰 네트워크를 유지할 수 잇는지에 대해 알아볼 것이다. 



거래 전송하기


거래에 필요한 정보가 거래 자체에 모두 포함되어 있기 때문에 거래가 비트코인 네트워크로 전송되는 방법이나 장소는 중요하지 않다. 비트코인 네트워크는 P2P 네트워크로, 각각의 비트코인 고객이 여러 다른 비트코인 고객들에게 접속함으로써 네트워크에 참여하게 된다. 비트코인 네트워크이 목적은 거래내역과 블록을 참여자 전원에게 전파하는 것이다.



거래 전파하기


앨리스의 지갑 어플리케이션에서 유선, 와이파이 휴대폰 등 어떠한 종류의 인터넷이든 연결만 되어 있다면 여러 비트코인 고객들에게 새로운 거래를 전송할 수 있다. 비트코인 네트워크 노드(다른 고객들)가 이전에는 없던 유효한 거래를 전송받으면 즉시 연결되어있는 다른 노드로 해당 거래를 전달할 것이다. 이런 과정을 통해 거래는 .P2P 네트워크를 통해 급속도로 전파되고 몇 초 만에 비트코인 네트워크 내에 있는 노드 대부분에게 도달하게 된다. 



밥의 입장에서 거래 살펴보기 


비트코인 거래에 대해 가장 흔하게 하는 오해가 바로 새롭게 생성된 블록에 대해 10분을 기다리거나 위험요소를 최소화 하기 위해 필요한 6번의 승인을 위해 최대 60분을 기다려서 '승인'을 받아야 한다는 것이다. 물론 해당 거래를 전 네트워크가 수락했다는 사실을 확인하기 위해 승인 절차가 필요하기는 하지만 커피 한 잔 처럼 소액 결제에 대해서는 시간을 지연시킬 필요가 없다.



비트코인 채굴하기


이제 거래가 비트코인 네트워크상에 전파되었다. 하지만 이 거래가 검증되고 채굴(mining)이라는 과정을 거쳐 블록에 포함될 때 까지는 공유장부(블록체인)의 일부가 되지 못한다.(자세한 내용은 8장 참조)


 비트코인 신뢰 시스템은 수학적 계산에 기반을 두고있다. 각 거래들은 블록 단위로 묶여있고, 입증해야 할 수학적 계산의 규모가 엄청나지만 입증된 후에는 검증을 위해서 그다지 많은 계산을 하지 않아도 된다. 채굴 과정은 비트코인 시스템 내에서 두가지 목적을 가지고 있다.


- 채굴 과정은 돈을 새로 발행하는 중앙은행처럼 각 블록 내에서 새 비트코인을 생성한다. 한 블록당 생성되는 비트코인의 양은 고정되어있고 시간이 지나면서 줄어든다.


- 채굴 과정은 거래를 담고 있는 블록이 충분한 연산력을 사용하여 승인되었다는 것이 확인 되었을 때만 신뢰가 생긴다.


이 게임은 누군가 솔루션을 찾아낼 때마다 리셋되고 솔루션을 찾는데 걸리는 시간이 10분정도가 되도록 난이도가 자동적으로 조절된다. 


약 10분마다 거래가 담겨있는 블록에 대한 솔루션을 찾기 위해 전 세계적인 경쟁 속에서 수천명의 다른 채굴자들과 함께 채굴 작업을 하고 있다. 작업 증명이라고 불리는 이 솔루션을 찾는 작업을 위해서는 전 비트코인 네트워크에 걸쳐 1초당 수천 조 건의 해싱 작업이 필요하다. 


작업 증명 알고리즘은 설정된 유형에 일치하는 솔루션이 나올 때까지 SHA256이라는 암호화 알고리즘을 이용해 블록의 헤더와 임의의 숫자를 반복적으로 해싱한다. 솔루션을 찾아낸 첫 번째 채굴자가 이 경쟁의 승자가 되고 채굴한 블록은 블록체인으로 올라간다.


비트코인 네트워크에 합류하는 채굴자들이 늘어나면서 문제의 난이도가 빠른속도로 높아졌다. 초기에는 CPU 연산 -> GPU -> ASIC(하나의 실리콘 칩위에 동시에 가동되는, 하드웨어상에 수백 개의 채굴 알고리즘이 새겨져 있는 주문형 반도체)을 사용할 때에만 수익성이 있었다.




블록에 담겨있는 거래 채굴하기


네트워크로 전송된 거래는 전 세계적으로 분산되어 있는 장부인 블록체인에 올라가기 전에는 검증되지 않는다. 평균적으로 10분마다 채굴자들은 지난 블록까지의 거래 전부가 포함된 새 블록을 생성한다. 새로운 거래들이 사용자 지갑과 여러 어플리케이션으로부터 네트워크로 끊임없이 들어온다. 비트코인 네트워크 노드들이 이 상황을 지켜보다가 각 노드가 유지하고 있는 임시 풀(temporary pool)로 이 새로운 거래들을 추가한다. 이 임시풀에는 미검증 거래들이 들어있다. 채굴자들이 새 블록을 만들면서 이 임시 풀에서 새 블록으로 미검증 거래들을 추가한 후 새 블록의 유효성을 입증하기 위해 매우 어려운 문제(작업인증)를 풀려고 노력한다.


거래들이 새 블록에 추가될 때 거래 수수료가 가장 높은 거래부터 우선 순위로 추가되고 몇몇 거래는 다른 기준을 바탕으로 추가된다. 각 채굴자는 네트워크로부터 이전 블록을 받게되면 이전 경쟁 라운드에서 채굴에 실패했다는 사실을 알게 되고 바로 새 블록을 채굴하는 과정을 시작한다. 즉시 새로운 블록을 생성하고 이전 블록의 지문을 채운 후 새로운 블록에 대한 작업증명 계산을 시작한다.


각 채굴자는 자신의 블록 안에 특별한 거래 하나를 포함하고 있는데, 이는 자신 소유의 비트코인 주소에 새롭게 생성된 비트코인을 보상(현재는 한 블록당 25 BTC)으로 받는 거래다.




앨리스의 거래가 네트워크에서 선택되어 미검증 거래들로 이루어진 채굴 풀에 포함되었다. 징의 채굴하는 블록에 담겨서 징이 채굴에 성공하여 블록 #277316으로 발행함으로써 블록체인에 등록된다. 


몇 분 후, 새 블록인 #277317을 또 다른 채굴자가 채굴한다. 이 새 블록은 앨리스의 거래가 들어있는 이전 블록을 기반으로 하기 때문에 앨리스의 거래가 포함된 블록 위에 좀 더 많은 연산이 추가된다. 앨리스의 거래가 들어있는 블록은 해당 거래에 대해 한번의 '승인(Confirmation)'을 보유하고 있다고 간주된다. 새로운 블록이 추가되면 추가적인 승인을 받게된다. 각 블록이 거래를 담고있는 블록의 상부에 거래를 철회하기가 기하급수적으로 어려워진다. 따라서 해당 거래는 네트워크상에서 더욱더 신뢰도가 올라간다.



그림을 살펴보면 앨리스의 거래가 들어있는 블록을 볼 수 있다. 이 블록을 밑으로 277316개의 블록이 존재하며, 최초 블록 #0까지 체인으로 각자 연결되어 있다. 블록의 '높이(Height)'가 높아지면 각 블록과 체인의 계산 난이도도 전반적으로 올라간다. 앨리스의 거래가 들어있는 블록 이후에 채굴된 블록들은 더 강한 강도로 앨리스의 거래를 보증한다. 왜냐하면 체인의 길이가 길어질수록 수학적 계산의 수가 급격하게 불어나기 때문이다. 관례상 6회 이상의 승인이 이루어진 블록은 취소가 불가능하다(Six confirmation). 왜냐하면 여섯 개의 블록을 무효화해서 다시 계산하기 위해서는 엄청난 양의 계산이 필요하기 때문이다.




거래 소비하기


앨리스의 거래는 블록의 구성 요소로서 블록체인에 끼워져 있기 때문에 비트코인 분산 장부의 구성요소가 되며, 모든 비트코인 어플리케이션에서 확인할 수 있다. 풀 인덱스 클라이언트의 경우 비트코인이 블록 내에서 처음 발생하여 점차 이 거래에서 저 거래로 이동해서 최종적으로 밥의 비트코인 주소에 도달할 때까지 돈의 출처를 추적할 수 있다. 라이트웨이트 클라이언트의 경우 해당 거래가 블록체인 내에 존재하고 그 후 채굴된 블록이 여러 개 있다는 점을 승인함으로써 소위 말하는 단순지불검증(SPV)을 시행할 수 있다. 이를 통해 해당 네트워크가 해당 거래를 유효하다고 수락했음을 확증할 수 있다.


 밥은 이렇게 생성된 출력값을 참조해서 입력값을 정한 후 새로운 소유권을 배정받고 나서 본인의 소유의 거래를 생성한다. 이 과정을 거치고 나면 밥은 이제 앨리스와의 거래 및 다른 거래로부터 나온 출력값을 소비할 수 있다.



Ch1 에서는 주요 개념과 용어를 설명하고 필요한 소프트웨어를 파악하면서 간단한 거래에서 비트코인을 사용하는 방법을 소개한다.



비트코인 이전의 디지털 통화들


디지털 머니를 받는 사람들은 기본적으로 두가지 질문을 떠올릴 수 있다.


1. 이 디지털머니가 위조가 아닌지 신뢰할 수 있는가?

2. 이 돈을 내가 아닌 자신의 소유라고 주장하는 사람이 나올 가능성이 있는가?(Double Spending문제로 알려져있다.)


실제 화폐는 정교하게 제작된 용지와 인쇄 기법을 이용해서 위조 지폐 문제와 끊임없이 싸우고 있다. 또한 동일한 지폐가 동시에 다른 두 장소에서 사용될 수 없기 때문에 종이 화폐는 이중지불 문제를 쉽게 해결한다.


기존 화폐도 디지털상으로 보관되고 송금된다. 이 경우는 통화에 대해 영향력을 가지고 있는 중앙기관을 통해 모든 전자 거래를 승인함으로써 위조 지폐문제와 이중지불 문제를 처리한다.


디지털 머니의 가치에대한 정당성을 인정하는데에는 암호 기법이 그 근간을 마련해준다. 특히 암호화된 전자 서명은 사용자들로 하여금 디지털 자산 혹은 해당 자산에 대한 소유권을 제공하는 거래 시 서명을 가능하게 해준다. 적절한 아키텍처가 존대한다면 디지털 서명 역시 이중지불 문제를 해결하는데 사용될 수 있다.


비트코인은 암호 기법과 분산 시스템에 대한 수십 년간 연구의 정점을 찍는 결과물로, 독창적이고 강력한 특성을 통해 다음 네 가지 측면에서 혁신적인 화폐라 할 수 있다. 


비트코인의 구성 요소는 다음과 같다.


- 분산화된 P2P 네트워크(비트코인 프로토콜)

- 공개 거래장부(블록체인)

- 분산회된 수학적 결정론적 통화 발행(분산 채굴)

- 분산회된 거래 검증 시스템(거래 스크립트)



비트코인의 역사


비트코인은 2008년 사토시 나카모토라는 필명으로 "Bitcoin: A Peer-to-Peer Electronic Cash System"이라는 제목의 보고서가 발간되면서 세상에 등장했다. 


b-money 와 HashCash 등 이전에 발멸됐던 화폐들을 조합해서 완전히 분산화된 전자화폐 시스템을 창조했다.


비트코인 시스템은 통화 발행이나 거래에 대한 지불 및 검증을 위해 중앙 통제에 의존하지 않는다.


주요혁신 사항으로는 전 셰계적으로 매 10분마다 '투표'를 수행하기 위해, 분산 연산 시스템(즉 작업 증명 알고리즘)을 사용함으로써 분산 네트워크가 각 거래 상태에 대해 합의(Consensus)에 이를 수 있도록 했다는 점이다. 이러한 과정 덕분에 단일 통화 단위가 두번 결제되어 발생하는 이중지불 문제를 손쉽게 해결한다.


비트코인 시스템은 완전히 투명한 수학 원리에 의해 운영되기 때뮨에 사토시 나카모토를 비롯한 그 누구도 이 시스템을 통제할 수 없다. 




분산 컴퓨팅 문제에 대한 해결책


사토시 나카모토가 비트코인을 발행하면서 '비잔티움 장군 문제(Byzantine General's Problem)'로 알려져 있는, 분산 컴퓨팅 분야에서 예전부터 풀지 못했던 문제에 대한 실용적인 해결책이 마련되었다.


간단하게 설명하면 비잔티움 장군 문제는 신뢰성이 없고 임시로 구성된 네트워크상에서 정보를 교환함으로써 행동방침에 대해 동의를 구하고자 하는 과정에서 발생한다. 


사토시 나카모토의 해결책은 신뢰성이 있는 중앙 기관의 존재가 없는 상태에서 네트워크의 동의를 얻기 위해서 작업 증명 개념을 이용한다. 





비트코인의 사용과 사용자들, 그들의 이야기


Skip(실제 사용되는 사례를 예로들고 구체적인 내용은 뒤에 설명한다고 쓰여있어서 이부분은 생략)



비트코인 시작하기


비트코인 네트워크에 가입해서 비트코인을 쓰려는 사용자라면 어플리케이션을 다운로드 하거나 웹 어플리케이션을 사용해야 한다. 비트코인은 표준이기 때문에 비트코인 클라이언트 소프트웨어에 대한 여러가지 구현 버전과 참조 구현이 있다.


참조구현의 경우 사토시 클라이언트(Satoshi client)로 알려져 있으며, 사토시 나카모토가 만든 기본 구현을 근간으로 개발팀이 오픈 소스 프로젝트로 운영하고 있다.


비트코인 클라이언트의 유형으로 크게 세 가지가 있다.



풀 클라이언트(Full Client)


풀 클라이언트 혹은 '풀 노드(full node)'는 비트코인 거래 정보를 전부(모든 사용자가 현재까지 진행한 거래내역 전부) 저장하고 비트코인 사용자들의 지갑을 관리하며 비트코인 네트워크상으로 직접 거래를 만들어 낼 수 있다. 이러한 특징은 어떤 서버나 제 3자의 서비스와 관계없이 프로토콜의 모든 측면을 처리하는 독립형 이메일 서버와 유사하다.


- 사용자들을 위해 최고수준의 통제와 독립성을 제공하지만 그에 따라 사용자들은 백업과 보안에 대한 부담을 지게된다.

- 적적한 백업 없이 풀 클라이언트를 이용하게 되는 경우 컴퓨터에 문제가 생기게 되면 자금을 잃을 수 있다.



라이트웨이트 클라이언트(Lightweight client)


라이트웨이트 클라이언트는 사용자의 지갑을 저장하긴 하지만 비트코인 거래나 네트워크에 접근하기 위해서는 제 3자가 소유한 서버에 의존한다. 라이늩웨이트 클라이언트의 경우 거래내역 전부에 대한 복제본을 저장하지 않기 때문에 거래 검증을 위해서는 제 3자 서버에 의존해야 한다. 이는 네트워크와 소통하기 위해 제 3자에게 의존하고 메일함 사용을 위해 메일 서버에 접속하는 독립형 이메일 클라이언트와 유사하다.



웹 클라이언트(Web Client)


웹 클라이언트는 웹 브라우저를 통해 접속하며 제 3자가 소유한 서버상에서 사용자의 지갑을 저장한다. 이는 전적으로 제 3자가 서버에 의존하는 웹 메일과 유사하다.


설치와 사용이 가장 쉽지만 보안과 통제에 대한 문제를 사용자와 웹 서비스 소유주가 공유해야 하는 위험이 있다. 많은 사례를 통해서도 알 수 있듯이 웹 지갑 서비스가 공격을 받는 경우 사용자들은 자금 전부를 잃게 될 수도 있다.




다음 부분은 비트코인 클라이언트인 멀티비트에 대한 튜토리얼과 이 어플리케이션을 사용해서 비트코인 장만 및 송수신 방법등의 순서를 소개한다.
























비트코인 라이트닝 네트워크(Lightning Network) (1/2) 강의 내용정리


강의 링크 https://www.youtube.com/watch?v=4yUd8pL8JMI





라이트닝 네트워크란?


- 2015년 Joseph Poon과 Thaddeus Dryja에 의해 소개

- 비트코인의 확장성(Scalability) 문제를 해결하기 위한 솔루션

//이더리움의 샤딩, 코스모스 및 폴카닷 텐더민트등의 인터 블록체인, IOTA나 EOS같이 블록체인을 병렬화 시키거나 1차원적인 구조에서 2차원적인 구조로 만드는 솔루션 등등 여러 솔루션등이 있다. 비트코인은 초당 3~5개의 Transaction만 처리가 가능하기 때문에 글로벌하게 사용하기 어렵다는 문제가 있다.


- 블록체인 외부(Off blockchain)에서 결제 채널의 네트워크를 통해 낮은 수수료로 다량의 소액거래(micropayment)를 처리할 수 있도록 하는 시스템

// On은 블록체인 자체의 용량을 증가시키는 방법으로 하는것. Off blockchain으로 분류되는 이유는 블록체인 위에 결제채널을 만들어서 블록체인 외부에서 해결하는 방법이기 때문이다. 이론적으로는 Lightening Network는 약 초당 10억건 이상의 거래를 처리할 수 있다고 한다.


- 거래 가변성(Transaction Melleablilty)문제가 해결되어야 구현가능. 세그윗(SegWit) 구현 필요

// 현재 비트코인 네트워크에서는 구현이 안된다. 그 이유가 거래 가변성(혹은 거래 ID의 가변성, 동일한 내역의 거래가 다른 여러 ID를 가질 수 있다. 나는 한명인데 여러 ID를 가질 수 있다는 문제, 필수 조건, 이 문제를 해결하는 것이 SegWit이다. )




White Paper을 읽을 수 있다. 59페이지 내용이기 때문에 나중에 시간이 있으면 읽을 예정이다.


// 라이트코인같은 경우에는 비트코인과 유사한 구조에서 SegWit을 구현하여 Lightening Network를 구현하였다. 


참고자료1. Lightening Network에 대한 Joseph Poon 해외 강의

https://www.youtube.com/watch?v=8zVzw912wPo


참고자료2.

Raiden Network라는 이더리움의 라이트닝 네트워크에 대한 자료


참고자료3.

Plasma: Scalable Autonomous Smart Contracts (이더리움에 스마트 컨트랙트로 또 다른 블록체인을 생성해서 블록체인에 Child 블록체인을 만든다?)



"Bitcoin Doesn't Scale"


- 1MB blocks: // 현재 비트코인 블록의 사이즈

-- 7transaction per second @ 250 bytes/tx

-- ~220 million transaction per year  // 1년에 처리되는 트랜잭션의 양

-- Not enough for a city, let alone the world // 하나의 도시에서 사용되기에도 너무 부족하다


- 1 Billion transaction per day:  // 하루 10억건의 거래가 발생한다는 가정이하

-- 1.6 GB blocks(1655 MB)  // 블록마다 1.6GB의 용량이 필요

-- 87 Terabytes/year (87029089 MB)  // 1년에 약 87 TB의 용량

-- Maybe enough for one large metro area?

-- Centralization(mining!)  // 이렇게 되면 발생하는 문제가 채굴의 중앙화의 문제가 발생한다.


● 7 billion people doing 2 blockchain transactions per day // 만약 전세계 70억명이 매일 2건씩의 Blockchain 거래를 진행한다면

○ 24 GB blocks //블록 사이즈

○ 3.5 TB/day // 하루에 증가되는 용량

○ 1.27 PB/year // 연간 증가되는 용량


● Bigger blocks = Centralization // 블록이 커지면 중앙화가 발생할 것이다.

○ Very few full nodes // full node의 수가 줄어들고

○ Very few miners  // 채굴자도 줄어들고

○ De facto inability to validate blockchain  // 이러할 경우 누구나 검증할 수는 있지만 누구도 검증하려고 하지 않을 것이다.



결제 채널(payment channel)의 형성 기본 절차


output script: 2<Alice_pubkey><Bob_pubkey> 2 CHECKMULTISIG



Alice와 Bob이 결제 채널을 형성하고자 할 때의 기본 절차는 다음과 같다.


1. Funding Tx(F) 생성 //Alice와 Bob이 결제채널을 형성한다고 한다면 먼저 Funding Tx를 생성한다. 얼마를 넣을지 결정, 


output script:  2 <Alice_pubkey> <Bob_pubkey> 2 CHECKMULTISIG

//이 출력값으로 Funding Tx를 생성한다. 이 의미는 Alice와 Bob이 넣은 돈은 Alice와 Bob 둘의 서명을 모두 넣어야 사용이 가능하다.


2. Commitment Transaction 생성

// Funding Tx를 생성해놓고 서명하기 전에, Alice와 Bob이 0.5 씩 넣은것을 refund하는 Transaction을 생성한다.


3. Commitment Transaction 서명

// 이 Commitment Tx를 먼저 서명한다.


4. Commitment Transaction 서명교환

// 서명을 교환한다. 이러면 Commitment Tx이 유효한 Tx가 된다.


5. Funding Transaction 서명


6. Funding Transaction 서명교환


7. Funding Transaction Broadcast


- Commitment Transaction은 블록체인에 공개되지 않으며 거래 당사자간의 현재 잔고(current Balance)를 나타냄


- Alice와 Bob은 자신이 원할 때에 Commitment Transaction을 블록체인 상에 공개함으로써 자신의 잔고를 환불받고 결제채널을 닫을 수 있다.



- Alice가 Bob에게 0.1 BTC 송금 (Alice: 0.4 BTC, Bob: 0.6 BTC)

// 엘리스와 Bob이 Commitment Tx를 생성한다.


- 업데이트된 장부에 따라 새로운 Commitment Transaction을 생성한다.


문제점: Alice의 경우 이전 Commitment Transaction을 블록체인 상에 공개하는 것이 유리하다.


1. 두 거래중 어떠한 것이 유효한 것인지 구분하고


2. 이전의 거래를 무효화 해야 한다.



핵심: 어떻게 이전 Commitment Transaction을 무효화 시킬 것인가?


- 비트코인의 Timelock 기능을 사용하여 Commitment Transaction의 출력값을 취소할 수 있는 거래(revocable transaction)로 만들고


- 특정 당사자가 이전 Commitment Transaction을 블록체인에 공개하는 경우 해당 당사자를 식별하고


- 취소할 수 있는 거래를 취소하고 Breach Remedy Transaction을 통해 계약을 어기는 거래 참가자의 예치금을 몰수하는 방식으로 벌금을 부과




누가 잘못했는가? (Ascribing Blame)



- 항상 Commitment Tx을 생성할 때 Commitment 1a, Commitment 1b이렇게 똑같은 Commitment를 2개씩 한쌍으로 만든다.

- 한쪽에는 Bob만 서명하고 한쪽에는 Alice만 서명하고 상대방에게 넘긴다.

- 만약 Commitment 1a가 공개된 경우 이미 Bob의 서명이 기록되었기 때문에 Alice만이 서명하여 Broadcast할 수 있기 때문에 Alice가 공개한 Commitment Tx인지 알 수 있는것이다.

- 즉, 누가 어겼는지 확인하는 방법은 이렇게 반만 서명된 Transaction을 나눠가졌기 때문에 어떤 Transaction인지 보고 확인할 수 있다.


2. 취소할 수 있는 거래(Revocable Transaction)


- 만약에 Alice가 이전 거래(본인에게 0.5 BTC를 돌려주는 거래)를 등록하였을 경우 이 거래를 취소할 수 있어야 한다.


- 보라색은 Bob이 서명을 해서 Alice만이 등록할 수 있는 Transaction들이다. 1a의 경우 Locktime이 걸려있다 보면 1000 confirmations라고 되어있다.

- Alice가 C1a를 공개하면 0.5 BTC를 받는다. 받기는 받는데 이게 1000 block confrimation이 난 후에 받는다.

- 반면에 Bob같은 경우에는 바로 0.5 BTC를 받는다. 



- Alice가 Bob에게 0.1 BTC 송금 (Alice: 0.4 BTC, Bob: 0.6 BTC)

- 새로운 거래가 일어날 때마다 Commitment Tx 한쌍을 생성



- Funding(F) 는 Alice와 Bob이 0.5 BTC 씩 결제 채널에 예치금을 넣어놓는 형태로 그 안에서 자유롭게 Fund를 왔다갔다 할 수 있게하는 약속이다.

- C2 까지 양쪽이 모두 동의를 하여 Alice가 Bob에게 0.1 BTC를 줘야하는데 Alice가 C1a를 Broadcast한 경우를 가정한다.

- 이 경우 Bob에게는 바로 0.5 BTC가 전송되고 아래의 빨간 트랜잭션 RD1a가 발행되어 Alice는 1000 Confirmation 이후에 이 0.5 BTC를 가져갈 수 있다.

- 그 전에 Breach Remedy(벌금을 부과하는 Tx)를 Alice와 Bob모두 합의한다. BR1a는 "만약에 Alice가 C1a를 발행한다면 Alice의 0.5 BTC를 모두 Bob에게 몰수 한다" 라는 내용이다.

- 이 BR1a와 BR1b는 C2a,b가 생성되기 바로 이전에 먼저 서명을 하고 C2를 발행하는 것이다.

- 때문에 C2a,b가 나온 다음에 C1a가 Broadcast가 되면 Alice는 모든 예치금을 Bob에게 모두 잃는것이 된다.

- 이러한 Commitment Tx는 블록체인에 기록하지 않고 계속 진행되기 때문에 수수료 없이 계속 소액결제를 처리할 수 있는 것이다.



거래의 청산(Settlement)


- Commitment Tx는 실제로 합의를 하기위한 도구이고 실제로 모든 거래가 끝나고 청산을 하는 경우에는 Locktime과 같은 복잡한 내용 없이 Funding Tx와 같이 바로 모두가 서명하여 작성하여 청산한다.




요약


- 라이트닝 네트워크는 일련의 연기된(deffered) 비트코인 거래와 벌금 부과를 통해 블록체인 외부에서 거래 당사자들간의 거래를 이행되도록 한다.

- 블록체인은 법원(Court)의 역할을 하는데 모든 계약이 법원에 의해 강제되는 것은 아니지만 분쟁시 법원에 의해 강제될 수 있기 때문에 실제 대부분의 계약은 아무 문제없이 이행되는 것과 같은 원리이다.

- 결제 채널은 거래 당사자가 폐쇄하기로 결정하기 전까지 영구적으로(in perpetuity) 사용될 수 있으며 분쟁이 있는 경우 언제든지 비트코인 블록체인 상에서 그 분쟁을 해결할 수 있다.




Further Study


- 서로 채널을 형성하지 않은 사람들끼리도 안전하게 거래 가능(HTLC: Hashed Timelock Contract)

- 결제 채널들의 네트워크 형성, 네트워크 수수료, 예치금, 효율성, 투명성 vs 익명성의 문제

- 응용 및 확장 : Raiden, State Channel, Plasma. Sharding과 결합되는 경우





On the timestamps in the tangle


Serguei Popov∗


August 6, 2017



Description of the problem and proposed algorithms(문제 및 제안 알고리즘에 대한 설명)




다음에서 우리는 고정 된 순간의 Tangle [1]을 고려한다; 즉, Tangle의 상태는 고정되어 있으므로 간단히 T로 나타냅니다. 일부 표기법 : x가 Tangle의 사이트 (트랜잭션)이면 A(x)는 x에 의해 승인 된 두 트랜잭션 집합을 나타냅니다.  우리는 만약 xj 모든 j = 1, ..., k에 대해 xj  ∈ A(xj−1)에서 x = x0, x1, ... , xk = y 일련의 사이트가 있는 경우 x는 y를 참조(간접적으로 승인)한다라고 말한다. x와 관련하여 "과거"와 "미래"에 대해 이렇게 쓰도록하겠습니다.




다시 말하면, 상기는 Tangle에 부분 순서 구조를 도입합니다. 또한 우리는 참조하거나 참조하지 않는 트랜잭션 집합을 Ind (x) = T / (P (x) ∪F (x))로 나타냅니다. (약어 사용됨). x ∈ Ind (x)를 정의하면된다.


다음으로 각 트랜잭션 x에 대해 타임 스탬프 t (x)가 있다고 가정합니다. 즉, 원칙적으로, t (x)는 트랜잭션이 Tangle에 부착 된 시간에 대응한다. 모든 x ∈ T에 대해 A (x) = {y1, y2} 인 t(x)> t (y1,2)가 필요하다. 즉, 트랜잭션은 "미래의" Timestamp 인 다른 트랜잭션을 승인 할 수 없습니다. 우리의 상정 된 가정은 대다수 (합리적인 의미에서) 대다수의 트랜잭션이 신뢰할 수있는 시계를 장착 한 정직한 노드에 의해 발행 된 것입니다. 



이제 타임 스탬프 t (x)를 가진 트랜잭션 x (전형적으로, 이미 Tangle의 "깊은 내부"입니다.) 를 생각해보십시오. 문제는 그것이 정직하고 악의적인 노드(또는, 어쩌면 정직한 노드에서 어떤 이유에 의해 시계가 오작동해서 발생할 수도 있습니다.)에 의해 발행되었는지 알지 못한다는 것입니다. 그러므로 t(x)가 x가 Tangle에 부착 된 실시간(심지어 대략적인) Tx인지 확실하지 않습니다. 우리의 목표는 Tx에 대한 신뢰 구간 [ax, bx]를 구성하는 것이다. 즉, 이벤트 Tx ∈ [ax, bx]가 높은 확률로 발생하도록 (확정적인) ax ≤ bx를 원한다.


다음에서는 이러한 구간을 구성하기위한 두 가지 절차를 고려합니다.



Procedure 1. β ∈ (0, 1/2)를 고정한 다음, 데이터 수집을 고려한다 (사실, 다중 집합)


(t (y) : y ∈ Ind (x)).    (1)


그런 다음 ax와 bx를 상기 데이터 수집의 β-와 (1-β) - 분계선으로 정의하십시오.  β = 0 (즉, 위의 데이터 수집에서 ax와 bx를 최소값과 최대 값으로 취하는 것)이 좋은 아이디어가 아닌 이유를 설명해야합니다. 그 이유는 악의적인 개체가 ax를 0(과거의 다른 거래를 승인하는 새로운 거래를 발행하고 작은 t- 값을 가짐)으로, bx(x를 참조하지 않고 매우 큰 t- 값을 갖는 새로운 트랜잭션을 발행함으로써)를 무한하게하여 절차를 망칠 수 있기 때문입니다. β가 0에서 멀어지면 "분열"거래가 중단됩니다.


원칙적으로 β를 증가시킴으로써 위에서 설명한 악성 행동에 대한 방어력을 강화합니다. 반면에 β가 1/2에 "too close" 하다면 결과는 "too random"할 것이다(x가 정직한 노드에 의해 발행 된 경우 라 할지라도, β가 1/2에 가까울 때, t (x) 자체가 신뢰 구간으로 갈 수 없다는 것을 관찰 할 수있다)). 현재로서는 β의 "최적"값이 무엇인지는 불분명합니다. 실제로, 네트워크에서 악의적 인 노드의 비율과 이러한 분석을 수행하는 방법에 대한 가정을 만들어야합니다. 어쨌든, 경험적으로 [0.2,0.3]의 β 값이 효과가있을 것입니다. 


위의 절차의 단점으로, 각 x에 대해 개별적으로 계산을 수행해야한다는 점에 유의하십시오 (일반적으로 x != y 일 때 Ind(x) != Ind(y)를 관찰하십시오). 이것은 Tangle이 매우 큰 경우를 대비하여 계산상의 차이를 야기 할 수 있습니다.  On the other hand, the outcome of the procedure is deterministic, provided of course that the nodes use the same β and see the same state of the tangle. 


이제는 계산이 더 쉽고 동시에 많은 트랜잭션에서 작동하는 또 다른 절차를 설명하겠습니다. 반면에, random1 결과를 생성합니다. 



Procedure 2. Tangle의 깊숙한 곳에서 시작하여 [1]의 4.1 절에 설명 된 Random Walk를 실행하고 x가 참조하는 마지막 트랜잭션의 타임 스탬프가되도록 ax를 취하고, bx는 x를 참조하는 첫 번째 트랜잭션의 타임 스탬프가됩니다. 


악의적인 노드가 고정된 트랜잭션의 타임 스탬프를 위조하려고 시도하면, 이 트랜잭션은 Random Walk에 의해 선택되지 않을 것임을 관찰하십시오. 실제로, 악의적인 노드가 "과거로 부터의" 타임 스탬프를 두는 경우(즉, t (x)는 x가 발행 된 실제 시간보다 훨씬 크다), 이는 [1]의 섹션 4.1의 "Lazy Tip" 사례에 해당합니다. 그러한 거래는 오랜 시간 동안 누군가에 의해 참조되지 않을 것이고, 다시 Random Walk가 결국 그것을 통과하지 않을 것입니다.




Conclusion


Tangle은 트랜잭션의 정확한 시간 순서를 설정하기에 부적합한(사실, 일반적으로 불가능한) 부분 순서 구조만 있는 그래프입니다. 모든 트랜잭션에 타임 스탬프가 있어도 이 모든 타임 스탬프가 정확하다는 것을 확신 할 수 없습니다(거래가 나타나는 실제 시간에 대해 네트워크를 속이는 일부 악의적인 노드 및/또는 잘못된 시계가 있는 일부 노드가 있을 수 있습니다). 그럼에도 불구하고 합당한 정확도로 타임 스탬프의 신뢰 간격을 결정할 수 있습니다. 위의 텍스트에서 우리는이를 수행하기위한 두 가지 알고리즘을 설명했습니다; 첫 번째 것은 계산적으로 더 복잡하지만 결정론적(deterministic) 결과를 산출합니다 (동일한 β를 사용하고 Tangle의 동일한 상태를 보는 두 개의 노드는 동일한 신뢰 구간을 얻을 것이다). 다른 알고리즘은 더 간단하고 동시에 여러 트랜잭션에 대한 타임 스탬프의 신뢰 간격을 결정하지만 임의의 결과를 생성합니다 (랜덤 워크가 실제로 선택한 경로에 따라 다름).




References


[1] S. Popov (2015) The tangle. https://iota.org/IOTA Whitepaper.pdf


원문 출처:  https://medium.com/biilabs/in-depth-explanation-of-how-iota-making-a-transaction-bcdd9713b939


이 글은 IOTA에서 Transaction이 어떻게 생성되는지에 대한 설명을 담은 원문을 한글로 번역한 것 입니다. 오역이 있을 수 있으니 원문과 비교하여 읽으면 도움이 될 것 같습니다.



In depth explanation of how IOTA making a transaction




이 게시물은 IOTA가 트랜잭션에서 번들로, 해시에서 주소로, 개인 키에서 서명 메시지로 트랜잭션을 만드는 방법을 자세히 설명합니다. 이것은 IOTA가 한 주소에서 다른 주소로 거래를 제안하는 방법을 알기 위해 필요한 전부입니다.


0. Before We Start


이 두 가지 자료를 이미 읽었는지 확인하십시오. 당신에게 IOTA 거래의 기본 견해를 제공합니다.

  1. 1. Bundles — IOTA Documentations (https://iota.readme.io/v1.2.0/docs/bundles)
IOTA는 계정과 같은 체계를 사용합니다. 즉, 토큰을 전송하기 위해 지출해야하는 입력 사항 (주소)이 있음을 의미합니다. 주소는 개인 키에서 생성되며, 개인 키는 다시 try-encoded 시드에서 파생됩니다. IOTA에서의 Transfer(전송)은 산출물과 투입물로 구성된 번들입니다. 번들은 원자 전송(atomic transfers) 방식으로, 번들 내부의 모든 트랜잭션이 네트워크에 의해 받아 들여 지거나 전혀 사용되지 않습니다. IOTA의 일반적인 전송은 4 개의 트랜잭션으로 구성된 번들입니다.

     index

    Purpose 

    Value

    0

    Output . 거래 수령자 (Recipient of the transaction)

     > 0 (as defined by user)

    1

     주소 입력 전체를 소비하는 첫 x 째 번들 항목.  또한 이 번들 항목은 서명의 첫번째 부분을 포함합니다 (이 경우에는 Alice의 서명의 전반부가 됩니다)

     < 0 (spending of input)

    2

     Alice의 서명의 후반부 

    0

     Output . 나머지가있는 경우 (Alice가 각 키 인덱스에서 전체 잔액을 지출하지 않은 경우) 나머지 주소로 전송됩니다.

     > 0 (Input - output)


번들의 고유 한 기능은 트랜잭션이 번들 해시 뿐만 아니라 trunkTransaction을 통해서도 식별된다는 것입니다. 즉, Tail transaction(currentIndex : 0)은 trunkTransaction에서 트랜잭션 해시를 인덱스 1에서 참조하고, currentIndex 1 트랜잭션은 인덱스 2를 참조 (및 승인)합니다. 이렇게 하면 trunkTransaction을 순회하여 꼬리 트랜잭션에서 트랜잭션 번들 전체를 얻을 수 있습니다. 

단일 트랜잭션에는 분명히 여러 입력 및 출력이 포함될 수 있습니다.
  1. 2. Making a Transaction — IOTA Documentations (https://iota.readme.io/v1.2.0/docs/making-a-transaction)

앞서 언급했듯이 IOTA에는 채굴자(Miner)가 없습니다. 이와 같이 트랜잭션을 만드는 프로세스는 오늘날 블록 체인과 다릅니다. IOTA의 절차는 다음과 같습니다.

1. Signing: 개인 키를 사용하여 거래 입력에 서명합니다. 이 작업은 오프라인으로 수행 할 수 있습니다.

2. Tip Selection: MCMC는 트랜잭션 (branchTransaction 및 trunkTransaction)에서 참조 할 두 가지 팁을 무작위로 선택하는 데 사용됩니다.

3. Proof of Work: 네트워크에서 거래를 승인 받으려면 Bitcoin (스팸 및 sybil-resistance)이 아닌 Hashcash와 유사한 일부 작업 증명을 수행해야합니다. 이것은 보통 현대 PC에 몇 분이 소요됩니다.

이 작업이 완료되면 트랜잭션 객체의 trunkTransaction, branchTransaction 및 nonce가 업데이트되어야합니다. 즉, 거래를 네트워크에 지금 브로드 캐스트하고 다른 사람이 거래를 승인 할 때까지 기다릴 수 있습니다. 

1. The Steps to make a transaction



번들 만들기에는 모든 입력과 출력이 포함됩니다.

1. 출력 트랜잭션 준비

2. 입력 값이 출력 값을 만족할 때까지 입력 트랜잭션을 준비합니다.

3. Bundle hash를 얻고 모든 트랜잭션에 채우기 위해 최종 묶음

4. 서명 메시지 조각 작성에 대한 트랜잭션 처리

트렁크(trunk) 및 분기 해시(Branch hash)에 대한 두 가지 tip 얻기 

IRI getTransactionsToApprove를 통해


Proof of Work

1. 트랜잭션에 trunk branch hash 채우기

2. 태그가 설정되지 않은 경우 obsolete tag(오래된 태그)로 태그를 채우기.

3. 트랜잭션에 Timestamp 채우기

4. pearlDiver를 통해 nonce를 계산하고 Transaction hash를 얻습니다.

2. Making bundle


IOTA 번들에는 3 가지 유형의 트랜잭션이 포함되어 있습니다. Input transaction(입력 트랜잭션), Output transaction(출력 트랜잭션), and Meta transaction(메타 트랜잭션).

Input transaction: Transaction value가 음수
Output transaction: Transcation value가 양수.
Meta transaction: Transaction value 가 0, 그것은 서명의 carieer가 될 수 있거나 트랜잭션의 siganture 메시지 조각에 다른 메시지를 저장할 수 있습니다.


예를 들어 봅시다. A는 동일한 시드로부터 3 개의 주소를 가지며 몇개의 value를 가집니다.


Gather all transaction we need in bundle


- index 0: AAAAAAAA, balance: 50

- index 1: BBBBBBBB, balance: 70

- index 2: CCCCCCCC, balance: 20


A가 B의 주소 DDDDDDDD로 100i를 보낼 때, IOTA는 다음과 같이 할 것입니다 :


번들로 필요한 모든 거래를 모으기


B의 주소로 Output Transaction 준비 및 Bundle에 추가

Balance와 함께 A의 주소에서 Input Transaction 준비

Meta Transaction 슬롯을 사용하여 각각의 Input Transaction을 Bundle에 추가한다. 


메타 트랜잭션 슬롯 금액은 주소 보안 수준에 따라 다르며 주소의 기본 보안 수준은 2입니다. 즉, 트랜잭션 서명을 전달하는 데 하나의 추가 트랜잭션이 필요합니다.


번들의 잔액이 여전히 양수인 경우 사용되지 않은 출력 트랜잭션을 추가하여 소비되지 않은 값(Unspent value)을 이동합니다


Bundle finalized


 번들 Balance가 0인지 체크(입력 값 = 출력 값, Kirchhoff의 회선 법칙(Kirchhoff’s circuit laws)을 recall)



Generate bundle hash


- Kerl을 사용하여 transaction 유효성 검사 항목(address, value, obsolete tag, timestamp, current index, and last index)으로 흡수한다.


- Bundle trit을 집어 내고 Bundle hash로 변환한다.

- Secure bundle hash 생성 여부를 확인하고, 그렇지 않으면 obsolete tag(폐기 태그)를 증가시키고 다시 생성한다. (https://github.com/iotaledger/iota.lib.py/issues/84)


- 모든 트랜잭션에 Bundle hash 및 초기화 서명 조각을 채워넣는다 


- transaction hash, transaction tips, signature fragment and nonce가 이 단계에서 채워있지 않음을 확인하고 bundle hash만 결정됩니다.



Bundle signing


- seed를 통해 키 생성기(key generator) 가져 오기


- 트랜잭션을 반복하고 만약 트랜잭션이 Output transaction이면 이 transaction을 signing하려고 시도할 것이다(만약 필요하면 meta transaction으로). 


- 주소 index 및 security level으로 키 생성을 통해 Address private key를 얻는다.


- address private key와 bundle hash를 사용하여 signature fragment(서명 조각)을 생성하고 트랜잭션의 signature fragment 부분을 채 운다.


- 만약 security level이 2인 경우 2개의 transaction에 사인을 해야 한다. (output transaction과 다음 meta transaction인 경우 1개)



이 단계가 끝나면, bundle hash 및 transaction signature를 역순으로 (마지막 index부터 0 index 까지) transaction trytes들의 리스트를 얻는다.




3. Get two tips for trunk and branch


이 글에서 나는 MCMC 알고리즘을 다루지 않을 것이며, 이것을 블랙 박스라고 생각한다. getTransactionsToApprove를 통해 IRI로부터 두 가지 팁을 얻을 수있다.




4. Proof of Work


마지막 단계에서는 번들의 각 트랜잭션에 trunk, branch 및 nonce (여기에서 작업 증명!)를 채워야한다.


번들 설명서에 언급된 바와 같이, 번들은 Tangle 안의 Atomic transfer(원자적 전송) 항목이다. 즉, 하나의 bundle 안에서 같은 팁들을 가지고 있어야 한다.



그런 다음 Bundle의 모든 트랜잭션을 마지막 인덱스부터 0 인덱스까지 trunk, branch hash, time stamp을 채우기 위해 이동하고 nonce값을 찾ㄱ고 transaction hash를 생성하기 위한 PoW를 수행하고 PoW 결과의 유효성을 검사한다.


마지막 인덱스의 트랜잭션 트렁크와 분기 해시는 우리가 얻는 이전 팁이 될 것이다. 다른 트랜잭션의 트렁크는 이전 트랜잭션의 해시이고 분기 해시는 팁의 트렁크 트랜잭션이다. 



모든 것이 제대로 되었으면 모든 필드가 채워진 전체 트랜잭션 trytes를 얻을 수 있습니다!



5. PoC code for Python with PyOTA



# -*- coding: utf-8 -*-
# This is a POC code to generate IOTA transaction and bundle
#
# Note: You will need to implement getTransactionsToApprove
#
import iota
import pearldiver
SEED = 'GENERATE_YORU_SELF'
tag = iota.Tag('TESTINGPYTHON')
pt = iota.ProposedTransaction(
address=iota.Address('9TPHVCFLAZTZSDUWFBLCJOZICJKKPVDMAASWJZNFFBKRDDTEOUJHR9JVGTJNI9IYNVISZVXARWJFKUZWC'),
value=90,
tag=tag,
message=iota.TryteString('HELLO')
)
pb = iota.ProposedBundle([pt])
# pb.add_inputs([list])
# pb._create_input_transaction(addy)
addy = iota.Address('INDTKDAH9GGWDAJDWQLWUKCIHSYNEFQUGVHOYWLZRYPEZIZYQHQJNDLDPCLWMMO9UAEZUWPHMWZRLWGOB')
addy.balance = 100
addy.key_index = 2
addy.security_level = 2
inputs = [
iota.ProposedTransaction(
address=addy,
tag=tag,
value=-addy.balance
)
]
for input in inputs:
pb._transactions.append(input)
for _ in range(addy.security_level - 1):
pb._transactions.append(iota.ProposedTransaction(
address=addy,
tag=tag,
value=0
))
# send unspent inputs to
unspent = iota.Address('HWFZCLVY9RPTAWC9OIOSHXSWFIYMSYSYBHZER9BYZ9KUPUJTRUOLKSGISILWFCWJO9LNZOLWRCJMVDJGD')
pb.send_unspent_inputs_to(unspent)
# This will get the bundle hash
pb.finalize()
# If the transaction need sign, it will then sign-up the transaction
# to fill up signature fragements
kg = iota.crypto.signing.KeyGenerator(SEED)
# pb.sign_inputs(kg)
i = 0
while i < len(pb):
txn = pb[i]
if txn.value < 0:
if txn.address.key_index is None or txn.address.security_level is None:
raise ValueError
# pb.sign_input_at(i, kg.get_key_for(txn.address))
address_priv_key = kg.get_key_for(txn.address)
# Fill in signature fragement
# address_priv_key.sign_input_transactions(pb, i)
from iota.crypto.signing import SignatureFragmentGenerator
sfg = SignatureFragmentGenerator(address_priv_key, pb.hash)
for j in range(address_priv_key.security_level):
txn = pb[i + j]
txn.signature_message_fragment = next(sfg)
i += txn.address.security_level
else:
i += 1
# Now each transaction have their signature into bundle
# this is the end of the transaction construction.
# We can now propose the transaction to tangle
# At this moment, tips still not inside each transaction,
# and each transaction hash is not yet generated
trytes = pb.as_tryte_strings()
# Get tips by getTransactionsToApprove
# tips = getTransactionsToApprove()
trunk_hash = iota.Hash('')
branch_hash = iota.Hash('')
# Do PoW (attach to tangle)
prev_tx = None
for tx_tryte in trytes:
txn = iota.Transaction.from_tryte_string(tx_tryte)
txn.trunk_transaction_hash = trunk_hash if prev_tx is None else prev_tx.hash
txn.branch_transaction_hash = branch_hash if prev_tx is None else trunk_hash
# Copy obsolete tag if tag field is empty
if not txn.tag:
txn.tag = txn.obsolete_tag
# Copy timestamp
txn.timestamp = None
txn.timestamp_lower_bound = None
txn.timestamp_upper_bound = None
# Do the PoW for this transaction
diver = pearldiver.PearlDiver()
trits = txn.trits()
diver.search(trits, min_weight_magniude, -1)
# Validate PoW
# transactionValidator.validate(txn.as_trits())


6. Conclusion


여기서는 IOTA가 트랜잭션을 사용하여 Bundle을 구성하는 방법과 bundle hash, transaction hash, trunk hash, branch hash 및 nonce.와 같은 트랜잭션의 중요한 부분을 채울 때에 대해 설명한다.


우리는 명확하게 알고있다 트랜잭션을 생성하는 모든 단계에서 IoT 디바이스의 핵심 부분은 본인의 Transaction에 Signing하는 부분만 신경쓰고 나머지 other output transaction, tip selection and PoW 는 해당 디바이스에서 수행될 필요가 없다.






1 Abstract


인증은 모든 형태의 원격 통신에 필수적입니다. 인증의 부재는 중간자 공격 (man-in-the-middle attack)의 문을 열어 주며, 핵심 순간에 수행된다면 전체 상호 작용을 파괴 할 수 있습니다. 현재 인터넷 인증 방식에는 인증 기관 및 신뢰 웹이 포함됩니다. 이러한 접근법은 모두 중요한 단점이 있습니다. 전자는 신뢰할 수있는 제 3 자에게 의존하여 중앙 실패 지점을 도입하고, 후자는 진입 장벽이 높습니다. Certcoin은 대체, 공개 및 분산 인증 방식을 제안합니다. Certcoin의 핵심 아이디어는 도메인 및 관련 공개 키의 공개 원장을 유지하는 것입니다. Certcoin 구성표와 스마트 폰과 같이 제한된 저장 용량을 갖춘 장치에서 Certcoin을보다 쉽게 사용할 수 있도록 여러 가지 최적화 방법을 설명합니다. 우리의 최적화는 암호화 누적 기 및 분산 해시 테이블과 같은 도구를 사용합니다.




2 Existing Approaches to Authentication


1976 년에 공개 키 암호가 출현하기 전에는 대부분의 보안 메시지 전송이 이전에 일부 비밀 키 K를 공유 한 두 당사자 모두에게 의존하는 대칭 암호화 프로토콜을 사용하여 수행되었습니다. 공격자가 비밀 키를 추측 할 가능성은 매우 낮기 때문에 이 구조에서 인증은 간단합니다. K로 암호화 된 모든 개별 메시지는 인증 된 사용자로 간주됩니다. 그러나 통신하기 전에 키를 교환하는 것은 많은 수의 엔티티가 네트워크에 자유롭게 가입하고 탈퇴 할 수 있어야하며 네트워크상의 다른 엔티티와 안전하게 통신 할 수 있어야하는 인터넷과 같은 동적 환경에서는 비실용적입니다. 엔티티들의 수가 증가함에 따라 각 쌍의 엔티티가 자신의 공유 키를 빠르게 설정하는 것은 실행 불가능하게된다 [11].


공개 키 암호화는이 확장 성 문제를 해결합니다. ; 그러나 인증은 훨씬 간단합니다. 전통적인 공개 키 시스템에서 사용자는 메시지 수신자의 공개 키를 검색하고 해당 키로 암호화 한 다음 자체 서명 키로 메시지에 서명합니다. 그러면 수신자는 메시지를 해독 할 수있는 유일한 사람입니다. 그 사람은 비밀 암호 해독 키를 가진 유일한 소유자이기 때문입니다. 이 설정은 사전 키 협약의 필요성을 없애 주지만, 모든 엔티티가 이제 암호화를 생성 할 수 있기 때문에 발신자를 인증해야하는 문제가 발생합니다. 그는 디지털 서명을 기반으로 보낸 사람의 공개 키를 확인할 수 있지만 보낸 사람의 신원을 결정하기 위해 공개 키만 사용할 수는 없습니다 [21].


PKI (Public Key Infrastructure) 개념은 메시지 보낸 사람의 신원을 확인해야하는 필요성에서 비롯되었습니다. PKI는 일반적으로 각 개체의 공개 키를 증명하는 인증서를 발급합니다. 또한 PKI는 비밀 키가 유실되었거나 관련 개인이 악의적 인 것으로 간주 될 때 공개 키가 손상된 경우 인증서를 해지 할 수 있습니다. 현재 가장 일반적으로 사용되는 두 가지 접근 방식은 중앙 집중식의 신뢰할 수있는 제 3 자 인증 기관 (CA)과 종종 피플 - 피어 인증의 분산 네트워크 (Phil Zimmerman의 작성자 인 Phil Zimmerman PGP)



2.1 인증 기관


일반적으로 인증 기관 (CA)은 일반적으로보다 일반적인 선택으로 사용자 네트워크에 대한 디지털 인증서를 제공하고 관리하는 신뢰할 수있는 제 3 자 역할을합니다. 이를 수행하기 위해 CA에는 사용자 신원을 확인하고 Distinguish Name (DN, 예 : Google 또는 Facebook)을 할당하고 DN과 함께 공개 키를 기록하는 일종의 등록 프로세스가 있어야합니다. 이러한 레코드에는 데이터 암호화 또는 서명 확인 여부와 상관없이 키 용도에 대한 표시뿐만 아니라 만료 날짜가 포함됩니다. CA는 두 가지 목적을 수행합니다. 즉, 사용자가 특정 공개 키를 보유하고 사용자에 해당하는 공개 키의 조회를 용이하게하는지 확인하는 것을 용이하게합니다. 검증은 각 사용자에게 발급 된 인증서를 통해 수행됩니다. 그 인증서는 CA가 서명 한 "사용자 x가 공개 키 PK를 보유하고있는"형식의 진술입니다. 조회는 모든 사용자가 다른 개인의 공개 키를 요청하도록 허용하여 수행됩니다. 그런 다음 요청자는 해당 개인과 지식에 대한 지식이 없음을 증명함으로써 개인이 해당 비밀 키를 보유하고 있는지 확인할 수 있습니다. CA는 신뢰할 수있는 사람이 인증서를 신뢰해야하기 때문에 궁극적으로 네트워크 신뢰 에이전트 역할을합니다 [16].


이러한 레코드에는 데이터 암호화 또는 서명 확인 여부와 상관없이 키 용도에 대한 표시뿐만 아니라 만료 날짜가 포함됩니다. CA는 두 가지 목적을 수행합니다. 즉, 사용자가 특정 공개 키를 보유하고 사용자에게 해당하는 공개 키의 조회를 용이하게하는지 확인하는 것을 용이하게합니다. 검증은 각 사용자에게 발급 된 인증서를 통해 수행됩니다. 그 인증서는 CA가 서명 한 "사용자 x가 공개 키 PK를 보유하고있는"형식의 진술입니다. 조회는 모든 사용자가 다른 개인의 공개 키를 요청하도록 허용하여 수행됩니다. 그런 다음 요청자는 해당 개인과 지식에 대한 지식이 없음을 증명함으로써 개인이 해당 비밀 키를 보유하고 있는지 확인할 수 있습니다. CA는 신뢰할 수있는 사람이 인증서를 신뢰해야하기 때문에 궁극적으로 네트워크 신뢰 에이전트 역할을합니다 [16].


많은 엔티티는 비밀 키가 유실 된 경우 안전하게 비밀 키를 백업하고자 할 수 있습니다. 이를 수행하는 프로세스를 키 복구라고하며 오늘날의 많은 CA가 제공하는 기능입니다. 해독 키가 손실되면 민감한 데이터 또는 중요한 데이터가 영구적으로 손실 될 수 있습니다. 다른 한편, 서명 키의 손실은 상대적으로 중요하지 않습니다. 이전에 서명 된 메시지는 여전히 공개 키로 검증 될 수 있으며 (취소되지 않았다고 가정) 사용자는 서명을 계속하기 위해 새 키 쌍을 간단히 얻을 수 있습니다. 또한 CA와 서명 키를 백업하면 CA가 키 소유자로 가장 할 수 있습니다. 따라서 CA가 서명 키가 아닌 암호 해독 키를 백업하는 것이 가장 적합합니다 [13]. 따라서 모든 사용자는 두 기능에 동일한 키 쌍을 사용하는 대신 두 개의 키 쌍 (암호화 및 서명)을 생성해야합니다.


최근에는 너무 많은 신뢰가 CA에 배치되고 있음을 보여주는 수많은 사건이있었습니다. CA는 해킹 당했고 (예 : DigiNotar 사건), 고객 (예 : TrustWave 사건)에 하위 루트 인증서를 발행하여 고객이 자체적으로 인증서를 발급 할 수있게했습니다.


이러한 사고를 방지하기위한 한 가지 방법은 CA의 작업에 투명성을 도입하는 것입니다. Google CertiPate 투명성 프로젝트 [3]는 정확하게 이것을 시도합니다. 그들은 세계적으로 독립된 서버를 숫자 (예 : ≤ 1000)에 대한 공용 추가 전용 로그를 유지할 것을 제안합니다. 이러한 각 로그 서버는 별도의 CA에 의해 실행될 수 있습니다. 그런 다음이 로그는 다른 공개적으로 실행되는 서버에 의해 의심스러운 인증서가 있는지 모니터하고 모든 사람이 실행할 수있는 경량의 감사 소프트웨어로 일관된 동작을 감사합니다. 이렇게하면 도메인의 소유자가 자신의 도메인에 대해 발급 된 모든 인증서를 볼 수있게되어 모든 잘못된 인증서를 발견 할 수 있습니다.



2.2 Web of Trust


실제로 사용되는 두 번째 주요 PKI는 PGP Trust of Web (WoT)입니다. 이 시스템에서는 인증이 완전히 분산되어 있습니다. 사용자는 자신의 공개 키에 서명함으로써 신뢰할 수있는 다른 사람들을 지정할 수 있습니다. 그렇게함으로써 사용자는 자신의 공개 키와 신뢰할 수있는 것으로 간주되는 엔티티의 디지털 서명을 포함하는 인증서를 누적합니다. 그런 다음 인증서는 자신이 신뢰하는 사람의 서명이 포함되어 있는지 확인할 수있는 경우 당사자가 신뢰할 수 있습니다 [21].


이 시스템은 중앙 집중식 장애 지점을 없애기 때문에 분산 된 성격을 활용합니다. 그러나 신원 또는 원격 사용자가 네트워크에 가입하는 것은 일반적으로 신원을 확인하고 공개 키를 처음 서명 한 사람과 만나는 것이 일반적이므로 만나야합니다. 또한 CA와 달리 WoT는 키 복구를 처리 할 방법이 없습니다. 사용자는 개인 키가 분실되거나 손상된 경우 자신의 인증서를 철회하도록 임명 된 다른 사용자를 자신의 "지정된 취소 자"로 선택하는 것으로 제한됩니다. 이러한 변화에도 불구하고, Trust of Web은 상당한 수정없이 거의 25 년 동안 성공적으로 운영되었습니다.



2.3 Certcoin: the Best of Both Worlds


투명한 인증 기관과 웹 신뢰의 장점을 통합 한 시스템 인 Certcoin을 소개합니다. Google CertiPate 투명성 프로젝트와 마찬가지로 Certcoin은 완전히 공개되고 감사가 가능합니다. WoT와 마찬가지로 Certcoin은 분산되어 있으며 단일 실패 지점이 없습니다. 우리는 3 절에서 Certcoin 프로토콜의 세부 사항을 제공합니다.



3 The Fundamental Certcoin Protocol(기본 Certcoin 프로토콜)


Bitcoin을 기반으로 한 새로운 분산 형 공개 키 인프라를 제안합니다. 주어진 신원 또는 도메인에 해당하는 공개 키를 신뢰할 수 있고 영구적으로 게시하는 기능은 인증 방법이 간단합니다. Bitcoin과 다른 cryptocurrencies는 정확히 같은 게시판을 구현합니다.


우리는 Namecoin [2] 위에 프로젝트를 분기하고 CertCoin 트랜잭션이 블록 체인에 제대로 구축되도록 병합 된 마이닝 프로토콜을 활용하여 Certcoin을 구축 할 것을 제안합니다. Namecoin은 .bit 주소에 대한 분산 DNS로 작동하도록 설계된 cryptocurrency입니다. 도메인 등록 및 업데이트를 지원하는 세 가지 유형의 트랜잭션 (이름 신규, 이름 갱신 및 이름 갱신)이 있습니다. 새로운 이름은 일반적으로 Namecoin이 0.01 단위 인 반면 나머지는 무료입니다.



3.1 Registering a Domain with Certcoin(Certcoin으로 도메인 등록)


도메인이 Namecoin에 처음 등록 될 때, 트랜잭션은 구매 된 사이트와 관련된 두 개의 공개 키에 대한 서명 된 정보를 포함합니다. 첫 번째 공개 키는 "온라인"키 쌍에 속하며 두 번째 공개 키는 "offline"키 쌍에 속합니다.

"온라인" 비밀 키는 웹 사이트를 호스팅하는 서버와주고받는 메시지를 인증하는 데 사용됩니다. 이 비밀 키는 Certcoin에서 웹 사이트를 인증하는 데 사용되는 기본 키이기도합니다. 인증의 일부로 해당 키 지식에 대한 증거가 필요할 것입니다.


"오프라인" 비밀 키는 인터넷에 연결된 장치에 저장된 결과 온라인 키가 직면하게 될 보안 위협과 동일한 보안 위협에 취약하지 않은 안전한 장소에 저장됩니다. 이 기본 키는 보안 위반이나 키 손상의 경우 새 키를 서명하거나 취소하는 데 주로 사용됩니다. 이에 대해서는 4.2 절에서 더 자세히 설명 할 것이다.


도메인에 대해 새 키를 만들면 같은 유형의 이전 키로 서명됩니다. 이렇게하면 언제든지 도메인에 등록 된 두 유효한 키를 일련의 서명 된 문을 통해 도메인에 등록 된 처음 두 키 쌍으로 추적 할 수 있습니다.



3.2 Updating a Public Key Corresponding to a Domain(도메인에 해당하는 공개 키 업데이트)


도메인 d에 해당하는 공개 키 pkold를 새로운 공개 키 pknew (동일한 온라인 / offline 형식)로 변경하는 것은 게시로 수행됩니다. 



우리 게시판으로 이동합니다. 여기서 σ는 보안 디지털 서명 알고리즘입니다. 우리는 여기에서 디지털 서명을 활용하여 새로운 공개 키가 이전 공용 키에 해당하는 비밀 키 보유자 만 게시 할 수 있도록합니다. 이 업데이트 트랜잭션은 서명이 pkold로 검증 된 경우에만 처리됩니다.



3.3 Verifying / Looking Up a Public Key(공개 키 확인 / 검색)


공개 또는 온라인 유형의 공개 키 pk가 도메인 d에 해당하는지 확인하는 것은 블록 체인을 탐색하고 다음을 확인하는 것입니다.


• 도메인 d가 정확히 한 번 등록되었습니다.

• d에 해당하는 공개 키에 대한 후속 업데이트의 모든 서명은 d의 이전 공개 키로 검증합니다.

• 마지막 업데이트로 pk가 d에 해당하는 공개 키가되고

• 도메인 d의 소유자라고 주장하는 사용자는 a zero-knowledge proof of knowledge를 사용하여 pk에 해당하는 비밀 키 sk를 알고 있습니다.



도메인 d에 해당하는 공개 키 pk (offline 또는 online 유형 중 하나)를 찾으려면 블록 체인을 탐색하고 다음을 수행해야합니다.


• 도메인 d가 정확히 한 번 등록되었는지 확인합니다.

• d에 해당하는 공개 키에 대한 후속 업데이트의 모든 서명이 이전 공개 키로 검증되었는지 확인합니다.

• d에 해당하는 공개 키에 대한 최종 업데이트를 찾고 업데이트가 발생한 공개 키 pk를 저장합니다.

• 도메인 d의 소유자라고 주장하는 사용자가 지식 지식이없는 지식을 사용하여 pk에 해당하는 비밀 키 sk를 알고 있는지 확인합니다. 제로 지식 지식 지식이 유효한 경우, pk를 리턴하십시오. 그렇지 않으면 ⊥를 돌려 준다.




4 Key Recovery and Revocation(키 복구 및 해지)


완전 기능 인증 시스템은 키 해지 및 복구를위한 일부 기능을 제공해야합니다. 특정 비밀 키가 손상되거나 도난 당하거나 단순히 만료 될 수 있습니다.이 경우 키 소유자는 이전 키를 폐기하고 새 키를 가져와야합니다. 마찬가지로 암호는 잊어 버릴 수 있으며 특정 복구 방법이 필요할 수 있습니다. 전통적인 인증 기관 시스템에서는 이러한 목적 중 하나를 달성하기 위해 단순히 고객 지원 부서에 전화 할 수 있습니다. 그러나 분산화 된 시스템에서는 처음부터 기계에 폐기 및 복구 메커니즘을 구축해야합니다.



4.1 Key Recovery(키 복구)


사용자가 도메인에 대한 비밀 / 공개 키 쌍을 생성하면 Certcoin은 비밀 키가 최소한 3 개의 신뢰할 수있는 "친구"사이에서 공유되는 복구 시스템(e.g. using the Shamir secret sharing paradigm [22])을 설정해야하며 재구성을 위해 최소 2 개의 임계 값이 필요합니다. 또한 향상된 보안을 위해 각 신뢰할 수있는 친구는 다른 사람의 신원을 알지 않아야합니다. 실제로는 다른 사람을 신뢰하기를 원하지 않는 사용자는 "친구"를 자신이 만든 여러 가지 Certcoin 계정으로 지정하여 이러한 보안 목표를 달성 할 수 있습니다. Bitcoin 지갑 관리 플랫폼 인 Armory [12]에서도 이와 비슷한 기술을 사용합니다. 여기서 Armory [12]는 지갑의 열쇠가 비밀리에 복구가 가능하도록 공유합니다.



4.2 Key Revocation(키 폐지)


전통적인 공개 키 인프라에서 인증서는 특정 연령대에 만료되거나 인증서 폐기 목록 (CRL) [10]에 추가되거나 온라인 인증서 상태 프로토콜 (OCSP) [14]을 통해 폐기됩니다. 


Certcoin은 lifetime 가치를 창출 할 수 있습니다. 각 공개 키는 관련 타임 스탬프를 가지며 공개 키가 Lifetime 보다 이전에 생성 된 경우 연령만으로 거부해야합니다. 공용 키는 전통적인 PKI와 마찬가지로 이유 코드(reason code)를 사용하여 수동으로 해지 할 수 있습니다. 원인 코드는 "지정되지 않음", "키 손상", "CA 손상", "변경된 상태", "대체 된 상태"또는 "작동 중지"중 하나 일 수 있습니다. 


항상 각 도메인에는 두 개의 연결된 비밀 키가 있습니다. 하나는 online 이고 다른 하나는 offline 인 것입니다. 서로 다른 State의 타협은 서로 다른 방식으로 대응 될 수 있습니다. Google은 공격자가 키에 액세스하고 공격자가 키를 도용하는 (즉, 도메인 소유자가 멀리있는 키에 액세스하는) 경우를 구분합니다.



• 공격자가 하나의 비밀 키만 액세스 할 수 있는 경우 : 실제 도메인 소유자는 여전히 자신의 비밀 키 모두에 액세스 할 수 있으며 두 키를 사용하여 작성한 하나의 키와 서명하려고 시도한 다른 키를 폐기하는 상태의 서명에 서명 할 수 있습니다. 그런 다음 도메인 소유자가 현재 두 키 쌍을 사용하여 손상된 키를 업데이트합니다. 마지막으로, 두 가지 이전 보안 키는 손상된 키의 모든 향후 작업을 무효로하는 문에 서명하는 데 사용됩니다. 이렇게 하면 실제 도메인 소유자는 다시 두 개의 비협조적인 키의 유일한 소유자가되며 공격자는 무효화 된 키에만 액세스 할 수 있습니다. 이 모든 진술은 블록 체인에 트랜잭션으로 게시되며 공개적으로 검증 할 수 있습니다. 블록이 많은 문이 하나의 블록에 나타날 수 있기 때문에 동일한 블록에서 해지 된 키 (자매 키로 서명되지 않은 키)로 서명 된 모든 새 키는 블록 내의 타임 스탬프에 관계없이 자동으로 무효화됩니다. 이렇게하면 공격자가 이전 키를 취소 할 때 바로 제어 할 수있는 새 키에 침입 할 수 없게됩니다.


• 공격자가 온라인 비밀 키를 도용 한 경우 : 도메인 소유자가 온라인 비밀 키에 대한 모든 액세스 권한을 잃고 공격자가 도메인 소유자가 키 복구 시스템을 통해 키를 복구하지 못하도록 관리합니다. 모든 비밀 키는 온라인 비밀 키에 의해 생성 된 모든 서명에 대해 거부권을 행사하기 때문에 모두 손실되지 않습니다. 도메인 소유자는 offline 비밀 키를 사용하여 손상된 온라인 키로 서명 된 모든 키를 무효로하는 명령문에 서명하고 손상된 키 자체를 해지 할 수 있습니다. 다음으로, 도메인 소유자는 새로운 온라인 비밀 키를 생성하기 위해 offline 비밀 키를 사용할 수 있습니다. 그런 다음 저장 공간을 확보하기 위해 비밀 키를 반환한다. 


• 공격자가 온라인 및 오프라인 키 모두에 액세스 할 수있는 경우 : 도메인 소유자는 여전히 두 키에 액세스 할 수 있습니다. 두 사람은 실제 도메인 소유자와의 상대를 구별 할 수있는 방법이 없으므로 두 키를 모두 사용하여이 키로 서명 된 현재 및 미래의 진술을 모두 무효화하는 성명서에 서명 할 수 있습니다.


• 공격자가 두 비밀 키를 훔친 경우 : 도메인 소유자가 더 이상 자신의 키에 액세스 할 수 없으며 Certcoin 프로토콜 내에서 그러한 상황을 처리 할 방법이 없습니다.



위에서 설명한 방식으로 비밀 키 손상을 해결하려면 먼저 손상을 발견해야합니다.



5 Cutting Down on Storage: Accumulators for Key Verification(저장 공간 절약 : 키 확인 용 축압기)


Certcoin을 배치하는 데있어서 한 가지 중요한 문제는 모든 Certcoin 사용자가 전체 블록 체인을 저장해야하는 것입니다. Bitcoin 블록 체인은 현재 16GB이며, 월 약 1GB의 속도로 증가하고있는 것으로 보입니다 [1]. Certcoin을 순진하게 구현하려면 검증을 수행하는 모든 장치 또는 엔터티에 대용량 저장 용량이 필요합니다. 그러나 이것이 항상 가능한 것은 아닙니다. 예를 들어 스마트 폰의 브라우저에는 사용 가능한 많은 저장 공간이 없을 수도 있습니다.


등록 된 도메인 및 키의 현재 상태 (즉, 도메인에서 현재 키까지의 맵) 만 유지하면 조금 더 나아질 수 있습니다. 여전히 등록 된 도메인 수에는 선형적인 저장 공간이 필요하지만 전체 블록 체인을 순회하는 것과는 달리 검사 당 일정한 시간 만 필요합니다. 또한 Bitcoin 프로토콜 [20]을 사용하여 추가 블록을 검증 할 수 있도록 블록 체인의 마지막 몇 블록을 저장해야합니다. 나머지 블록은 포함 된 공개 키 업데이트를 확인한 후 내용이 저장 상태를 업데이트하는 데 사용 된 후에 폐기됩니다. 그러나 등록 된 도메인 수가 선형화 된 저장 공간은 여전히 비현실적입니다. 스마트 폰의 브라우저는이를 지원할 수 없습니다.


우리는 Certcoin 저장 요구 사항을 낮추기 위해 Accumulator [15]의 사용을 제안합니다. Accumulator는 세트의 구성원을 테스트하는 데 사용되는 디지털 객체입니다. Accumulator 는 형식 (d, pk) 또는 형식 (d, pk, exp)의 튜플을 저장합니다. 여기서 d는 도메인이고, pk는 공개 키이고, exp는 선택적 만료 날짜입니다. 그런 다음 Accumulator 는 pk가 d에 등록되었는지 여부를 결정하는 데 사용될 수 있습니다. 대응하는 비밀 키 sk의 지식은 여전히 zero-knowledge proof 을 통해 증명 될 필요가있다. 이 절에서는 암호화 Accumulator를 설명하고 Certcoin에서 이 암호화 Accumulator를 사용하는 방법에 대해 설명합니다.



5.1 Cryptographic Accumulator Definitions(암호 누산기 정의)


디지털 서명에 대한 분산 형 대안으로서 암호화 Accumulator의 사용은 Benaloh와 de Mare에 의해 1994 년에 처음 기술되었다. Accumulator는 일련의 요소를 일정한 크기로 표현한 것입니다. Accumulator에 요소를 추가하면 증인이 생성되어 해당 요소가 추가되었음을 입증하는 데 사용할 수 있습니다. 보다 공식적으로, Accumulator 스키마는 4 개의 다항식 시간 알고리즘으로 구성됩니다.


• Gen (1^k) → a 

보안 매개 변수 k가 주어진 경우 빈 Accumulator의 초기 값과 추가 매개 변수를 생성합니다.


• Add (a, y) → (a', w) 

누산기 a의 현재 상태와 y 가산 값을 취하고 해당 증인 w뿐만 아니라 Accumulator a'의 새로운 상태를 반환합니다.


• WitAdd (w, y) → w' 

증인 w의 현재 상태와 새로운 값 y를 Accumulator에 가산하여 갱신 된 증인 w'을 반환한다.


• Ver (a, y, w) → {0,1}

Accumulator a의 현재 상태, a의 멤버가 확인되는 값 y 및 y가 a에 있는 것의 증인 w 그리고 y가 a에있는 것처럼 보이는 경우 1을 반환하고 그렇지 않으면 0을 반환합니다.


Accumulator는 다음과 같은 속성이있는 경우 안전합니다.


• Correctness(정확성) : 값 y가 일치하는 것의 최신 증인은 항상 최신 Accumulator에서 y의 멤버 자격을 확인하는 데 사용할 수 있습니다. 좀 더 공식적으로, 모든 유효한 값 y와 유효한 값 [y1, ..., yl1], [y1, ..., yl2]의 추가 집합



• Soundness(건전성) : y 멤버십에 대한 검증이 성공하는 방식으로 Accumulator에 추가되지 않은 값 y에 대한 증인 w를 제작하는 것은 어렵습니다. 보다 공식적으로,  oracles a에서 Add 및 WitAdd 블랙 박스 액세스가있는 어떠한 확률적인 polynomial-time 공격자 A에 대해



여기서 y는 Add를 호출하지 않은 A의 요소이고, a는 공격자가 Add에 대한 모든 호출을 한 후에 Accumulator의 상태이며, negl은 보안 매개 변수에서 무시할 수있는 함수입니다.



Accumulator에서 추가 속성이 필요할 수 있습니다.


• Compactness : Accumulator의 바람직한 특성은 얼마나 많은 항목이 추가 되더라도 작게 유지된다는 것입니다. Accumulator는 크기가 일정하면 (즉, 포함하는 요소의 수에 관계없이) 작다. 일부 Accumulator는 포함하는 요소의 수와 로그 적으로 증가합니다.


• Dynamism : 2002 년 Jan Camenisch와 Anna Lysyanskaya [9]는 삭제 알고리즘 Del과 증인 업데이트 알고리즘 WitDel을 사용하여 Accumulator에서 요소 삭제를 지원하는 동적 Accumulator의 개념을 도입했습니다.


• 보편성 (Universality) : 2007 년 Jiangtao Li, Ninghui Li와 Rui Xue [18]는 보편적 인 Accumulator의 개념을 소개했다. 보편적 인 Accumulator는 멤버쉽 증명 이외에 비회원 증명을 지원하는 Accumulator이다.


• Strength: • 장점 : 2008 년 Philippe Camacho, Alejandro Hevia, Marcos Kiwi 및 Roberto Opazo [7]는 Accumulator 관리자를 신뢰할 만한 것으로 간주하지 않는 강력한 Accumulator 개념을 소개하였다. 강한 Accumulator는 5.2.1 절에 설명 된 RSA Accumulator에서와 같이 Accumulator 생성 또는 유지 관리에 트랩 도어 정보를 사용할 수 없습니다. 




5.2 Cryptographic Accumulator Constructions(암호화 Accumulator 구조)


RSA 구성, Bilinear Map 구성 및 Merkle Hash Tree 구성을 포함하여 여러 가지 알려진 Accumulator 구조가 있습니다. Bilinear Map 구조의 속성은 RSA 구조의 속성과 비슷하므로이 백서에서는 이에 대해 자세히 설명하지 않습니다. 또한 우리는 이러한 Accumulator 이외에 블룸 필터 (Bloom Filter)는 증인을 활용하지 않기 때문에 기술적으로 암호화 Accumulator가 아니지만 효율적인 멤버십 테스트에도 사용할 수 있어 고려한다. 그림 1의 표에는 이러한 모든 구성의 일부 속성이 요약되어 있습니다.




5.2.1 The RSA Accumulator(RSA 누산기)


Benaloh와 de Mare [5]는 해쉬 함수 h : X × Y → X 인 준 환원 해쉬 함수로부터 Accumulator를 구성 할 것을 제안했다. 모든 x ∈ X와 y1, y2 ∈ Y에 대해


순서는이 해시 함수의 적용에 중요하지 않으므로 h(x, {y1, y2, ..., yn}) 를 h(h(...h( h(x ,y1), y2)...), yn).로 표시한다.


Accumulator는 고정 된 x로 시작하여 값 yi가 h에 반복적으로 적용되어 집합에 추가 될 수 있습니다. h가 단방향 함수일 경우 집합의 yi 값은 h(w, yi) = a 의 검사에 의해 주어진 증인 w = h(x, {yj} j != i)에서 Accumulator에 테스트 될 수 있다. 이것은 분명하다: 값 yi가 합법적으로 a에 추가되었다면 유효한 w = h (x, {yj} j != i)가 유지되었을 것이다. 이것은 또한 h는 단방향이기 때문에, 값 w와 yi는 주어진 a만을 얻는 것이 어렵다.


Zn* 의 거듭 제곱은 단방향 및 준 가변 (quasi-commutative)이며 다음과 같이 암호화 Accumulator를 구성하는 데 사용할 수 있습니다.



v를 충돌 방지 해시 함수(collision-resistant hash function)라고합시다.


v를 사용하는 것은 y = yi yj에 대한 명백한 증인 제조 공격(obvious witness fabrication attack)을 방지하기 위해 필요하며, 여기서 yi 및 yj는 Accumulator에 합법적으로 추가됩니다.


이 구성은 n의 인수 분해가 적에게 알려지지 않은 경우에만 안전합니다. 즉, n의 인수 분해는 trap door입니다. 그러나 이 trap door는 Accumulator를 사용하지 않고 Accumulator를 만드는 데만 필요합니다. Add, WitAdd 및 Ver 알고리즘은 모두 n의 인수 분해를 모른 채 수행 될 수 있습니다. 따라서 Gen가 trap door 정보를 사용하기 때문에 RSA Accumulator가 강력한 Accumulator가 아닌 반면 안전한 방식으로 Gen를 수행하고 (아마도 다중 사용자 계산을 통해) Accumulator에 결과 Accumulator를 제공함으로써 강력한 Accumulator manager를 만들 수 있습니다.



Jan Camenisch와 Anna Lysyanskaya [9]는 RSA 누산기를 동적으로 만드는 방법을 제시한다. 다음과 같이 삭제 알고리즘 Del 및 추가 미러링 모니터 업데이트 알고리즘 WitDel을 설명합니다.




Del과 WitDel은 Gen과 마찬가지로  trap door에 대한 지식이 필요합니다.




5.2.2 The Merkle Hash Tree Accumulator


Jiangtao Li, Ninghui Li와 Rui Xue [18]는 Merkle Hash Trees의 건축과 유사한 방식으로 Accumulator를 건설 할 것을 제안했다. 그들의 논문에서 제시된 구성은 보편적으로 설계 되었기 때문에 더 복잡하고 다소 효과적입니다. 보편성이 Certcoin Accumulator의 매우 중요한 자산이라고 생각하지 않기 때문에 비공식적으로 Merkle 해시 트리 구조의 약간 더 단순한 버전을 제시합니다.


h가 충돌 방지 해시 함수라 하자. 트리 깊이 i (i는 1부터 log(n) 까지의 집합의 원소)와 거의 같은 수준에서 이 Accumulator는 log (n) 평형 Merkle Hash Tree 뿌리의 목록을 유지하며,  여기서 n은 Accumulator의 요소 수이다.


a = [r1, ..., rlog (n)]이라 하자. 











6 Cutting Down on Storage: Distributed Hash Tables for Key Lookup(저장소 축소 : 키 조회를 위한 분산 해시 테이블)


암호화 Accumulator는 대용량 저장 오버 헤드를 발생시키지 않고 공개 키를 검증하는 문제를 해결합니다. 이제는 비슷한 제한이있는 공개 키를 가져 오는 문제로 넘어갑니다. Certcoin의 디자인은 인증과 배포를 명확하게 구분합니다. 도메인 구매 및 공개 키는 블록 체인에 저장되어 공개적으로 확인할 수있는 자격 증명 소스를 생성합니다. 불행히도 블록 체인은 본질적으로 키 - 값 검색을 지원하지 않으므로 동적 쿼리를 원활하게 수행 할 수 없습니다. 기존의 CA는 일반적으로 자체 인증 키 서버 역할을하므로 네트워크가 다른 사용자의 공개 키를 검색하도록 쿼리할 수 있습니다. 실용적인 PKI가되기 위해서는 CertCoin이 선택한 ID에 대한 공개 키를 효율적으로 검색하기위한 자체 인터페이스도 제공해야합니다. 이를 달성하기 위해 우리의 솔루션은 인증 된 DHT를 사용하여 구입 한 도메인 모음에 의해 유지 관리되는 탄력적이고 분산 된 키 서버를 만드는 방법을 제안합니다. 따라서 Certcoin의 배포 메커니즘은 자체 유지 키 전달 서비스를 만들기 위해 Kademlia DHT [19]의 고유 한 속성 중 일부를 사용합니다.


표준 형식에서 Kademlia는 인증되지 않아 중독, 라우팅 및 Sybil 공격에 취약합니다. 그러나 아래에서는 Certcoin의 블록 체인에 저장된 인증 데이터를 활용하여 각각 예방 방법을 설명합니다. 물론 우리는 도메인을 구입했는지 여부에 상관없이 모든 당사자가 Certcoin의 공개 키에 액세스 할 수 있기를 원합니다. 따라서 키 조회 요청을 인증하지 않기로 선택합니다. 이러한 요청의 읽기 전용 특성으로 인해 외부 공격자가 이 RPC를 악용하여 키 - 값 쌍을 변경할 수 없습니다. 따라서이 절의 나머지 부분에서는이 작업을 인증 문제에서 제외합니다.



6.1 Design of the Kademlia Distributed Hash Table(Kademlia 분산 해시 테이블 설계) // https://github.com/pRivAte12/kademila-kor


Kademlia가 제공하는 많은 바람직한 특성은 라우팅 테이블을 업데이트하기 위해 최소의 통신 오버 헤드를 발생시키는 대칭 라우팅 프로토콜의 결과입니다. Kademlia가 제공하는 많은 바람직한 특성은 라우팅 테이블을 업데이트하기 위해 최소의 통신 오버 헤드를 발생시키는 대칭 라우팅 프로토콜의 결과입니다. 이 프로토콜은 네트워크를 통해 전송 된 모든 패킷이 실행 가능한 노드 및 라우트의 상태에 대한 유용한 정보를 포함하도록 설계되었습니다. 따라서 Kademlia는 다른 노드에서 지속적으로 통신하고 사용자로부터 질의하여 장애를 자동으로 라우팅합니다. 따라서 Kademlia는 다른 노드에서 지속적으로 통신하고 사용자로부터 질의하여 장애를 자동으로 라우팅합니다.


또한 Kademlia는 라우팅 테이블에서 가장 오래된 활성 노드를 유지하려고 시도하여 노드 장애가 가동 시간과 반비례한다는 사실을 활용하여 가장 신뢰할 수있는 노드에 대한 경로가 위에 설명 된대로 네트워크의 다른 라우팅 테이블로 전파되도록 합니다 . 그런 다음 계속 증가하는 다른 라우팅 테이블에서 그 존재가 유지되는 방법으로 DHT의 노드가 온라인 상태를 유지하는 것이 가장 좋습니다. DHT의 응답 시간은 대상에 도달하는 데 필요한 숫자 홉에 따라 달라 지므로 신뢰할 수없는 노드는 공개 키에 액세스하려는 클라이언트에 대해 쿼리 응답을 느리게합니다. 이는 6.2.3에서 더 자세히 논의 된 Kademlia의 핵심 검색 프로토콜에 대한 Certcoin의 수정에 의해 시행됩니다.


모든 노드는 가능한 경로마다 k 개의 가능한 라우팅 값을 유지합니다. 이들 노드들 각각 사이에서 엔트리가 반복되지 않는다고 가정하면, 노드가 키에 도달 할 수 없다는 확률은 (2^-k)^k = 2^-k^2이다. 이것은 발신자의 테이블에있는 모든 k 노드가 임의의 노드로 들어오는 메시지나 나가는 메시지없이 자신의 라우팅 테이블에서 k 개의 실패를 갖도록 요구합니다. 그러나 중복은 확실히 발생해야하지만 네트워크의 라우팅 테이블이 본질적으로 가장 안정적인 노드를 저장한다는 사실에 의해 설정됩니다. 앞서 언급했듯이 라우팅 테이블은 보내거나받은 모든 메시지로 업데이트됩니다. 결과적으로 공격자가 구멍을 만들어야하는 평균 시간 간격이 비례하여 줄어들 기 때문에 더 많은 요청이 이루어짐에 따라 네트워크가 더욱 안전하게됩니다.


또한 Kademlia의 라우팅 프로토콜은 액세스 빈도에 따라 값을 분산하는 캐싱 메커니즘을 사용하도록 수정 될 수 있습니다. 네트워크의 많은 부분이 값을 복제 할 것이므로 더 많은 인기 키를 공격자가 목표로 삼기가 더 어려워 질 것입니다. 이를 달성하기 위해 필요한 추가 공간은 최소한이며 노드는 캐시 된 값을 계속 전파하는 노드가 많아짐에 따라 소스로 직접 트래픽이 감소하는 것을 볼 수 있기 때문에 노드가 참여할 수 있습니다.



6.2 Kademlia for Certcoin(Certcoin을위한 Kademlia)


Certcoin의 분산 형 키 서버는 표준 Kademlia 프로토콜에 3 가지 주요 변경 사항을 적용하여 공개 키의 무결성과 가용성을 제공합니다. 첫 번째는 디지털 서명을 사용하여 RPC에 인증 및 무결성을 제공하는 것입니다. 두 번째는 고유 한 노드 ID 할당 프로세스로 중요한 내성 Sybil 공격을 제공합니다. 마지막으로, 모든 노드가 DHT를 지원하고 시행 할 수있는 인센티브를 창출하여 자체 유지 특성을 갖게하는 수정 된 키 검색 프로세스로 결론을 내립니다. 키 배포에 참여하기 위해 각 도메인은 구입 한 도메인 이름으로 DHT 노드를 제공합니다. 노드가 네트워크에 입장하면 해당 도메인 이름의 해시를 키로 사용하여 공개 키, 감시 서버 쌍을 게시합니다. 간단하게하기 위해 나머지 섹션에서는 키 검색과 주어진 도메인 이름에 대한 검색을 모두 키 검색으로 사용하는 과정을 참조합니다. 



6.2.1 Authenticated RPCs(인증 된 RPC)


앞서 언급했듯이 인증되지 않은 DHT는 중독 및 라우팅 공격에 취약합니다. 다행스럽게도 노드가 Kademila의 RPC에 서명하도록 요구함으로써 쉽게 보호 할 수 있습니다. 우리는 노드 u에서 시작된 표준 메시지 M을 다음과 같이 Certcoin의 DHT에 적합한 인증 메시지 MAuth로 변환하는 방법부터 설명합니다.


PKu 및 WitnessPKu를 포함하면 수신자는 누적기를 사용하여 보낸 사람의 진 본성을 즉시 확인할 수 있습니다. 노드가 인증되지 않은 메시지를 라우팅을 업데이트하는 데 사용해서는 안되며, 이는 중독 공격을 유도하기 때문입니다. 따라서 노드가 특정 키에 대해 DHT 외부에서 인증되지 않은 쿼리를 수신하면 노드는 재귀 적이며 인증 된 키 검색 시퀀스를 시작하지만 해당 라우팅 테이블을 업데이트하기 위해 메시지를 무시합니다. 물론 대상 경로까지의 노드는 검증 된 RPC를 사용하여 테이블을 업데이트해야합니다



6.2.2 Node ID Assignment(노드 ID 할당)


더 많은 압박은 잘 알려진 시빌 공격에 대해 방어이다. 공격자는 대개 ID 공간의 특정 영역을 타겟팅 할 수있는 다수의 ID를 만들 수 있습니다. 인증 기관의 존재 여부를 결정할 수있는 응용 프로그램에서는 일반적으로 등록 프로세스를 통해 개체와 ID의 일대일 매핑을 보장함으로써 해결됩니다. CA의 교체가 Certcoin의 궁극적 인 목표이기 때문에 이것이 유효한 해결책이 아니라는 것은 분명합니다. 다행스럽게도 Certcoin과 블록 체인의 통합은 이미 등록 서비스를 제공합니다. 그런 다음 DHT는 H (도메인 이름, 공개 키 서명, 블록 타임 스탬프)에 해당하는 노드 ID를 만듭니다. 여기서 H는 단방향이며 충돌 방지입니다.



임의의 사용자가 작성한 쿼리에 대한 DHT의 응답을 보여주는 Certcoin의 대체 키(alternate key) 검색 프로토콜의 예입니다.





6.2.3 Key Retrieval(키 검색)


노드가 단순히 자신을 제거하고 네트워크의 나머지 부분에 키를 배포하지 못하게하려면 키 조회에 응답하는 모든 노드가 그 키와 연관된 호스트 이름의 하트 비트 메시지(물론 배열 경계 검사 포함)에 대한 응답을 수신 할 수있을 때만 응답해야합니다. 노드는 이를 수행하지 않으면 엔티티가 떠나도록 허용하고 나머지 노드에 응답 요청의 부담을가하므로이 확인을 수행 할 인센티브를 갖습니다. 또한 서버는 하트 비트 메시지에 응답해야하며, 그렇지 않으면 사용자는 해당 사이트의 공개 키를 검색 할 수 없습니다.


DHT 외부로 전달되는 쿼리 응답을 다른 인증 된 RPC와 똑같이 구성해야하므로 키 조회 절차의 보안을 강화할 수 있습니다. 이를 통해 누구나 부정확 한 응답을 게시함으로써 악의적 인 노드를보고 할 수 있습니다. 노드가이를 인식하게되면, 라우팅 테이블에서 노드 끝 노드를 즉시 제거해야합니다. 또한 호스트 이름과 연관된 값을 저장하는 모든 노드는 상기 키에 대한 요청을 존중하지 않아야합니다.


DHT 외부로 전달되는 쿼리 응답을 다른 인증 된 RPC와 똑같이 구성해야하므로 키 조회 절차의 보안을 더욱 강화할 수 있습니다. 이를 통해 누구나 부정확 한 응답을 게시함으로써 악의적 인 노드를보고 할 수 있습니다. 노드가 이를 인식하게되면, 라우팅 테이블에서 상한 노드를 즉시 제거해야합니다. 또한 호스트 이름과 연관된 값을 저장하는 모든 노드는 상기 키에 대한 요청을 존중하지 않아야합니다.



7 Conclusion


결론적으로, 우리는 Certcoin이 인증서 기관과 PGP Trusts of Web을 대신 할 수있는 실행 가능한 PKI라고 믿습니다. 우리의 구성은 내재 된 내결함성, 중복성 및 투명성을 비롯하여 완전히 분산 된 아키텍처에서 이익을 얻습니다. 그럼에도 불구하고 Certcoin은 인증서 생성, 해지, 연결 및 복구를 포함하여 완전한 기능을 갖춘 인증 기관의 예상 기능을 지원합니다. 도메인 구매 및 전송은 간단한 Bitcoin 트랜잭션으로 수행되어 Miner들에게 incentivize를 지급합니다. Certcoin은 암호화 어큐뮬레이터를 사용하여 도메인 인증을위한 일정한 크기의 저장소를 유지 관리합니다.이 저장소는 최근 인터넷 사용 추세에 따라 더욱 중요 해지고 있습니다. 마지막으로, 우리의 설계는 CertCoin을 성능에 민감한 응용 프로그램에보다 실용적으로 만들어주는 효율적인 키 검색을 제공하는 자체 유지, 신뢰할 수있는 키 배포 메커니즘의 필요성을 해결합니다. 또한 Certcoin은 신뢰할 수있는 제 3 자의 필요성 및 제한된 접근성과 같은 현재 PKI에 내재 된 많은 문제를 해결합니다.


우리는 미래에 Certcoin을 구현하여 우리의 결과를 경험적으로 발견하고 그 실행 가능성을 입증 할 수있는 추가 최적화를 모색 할 계획입니다.
















비트코인과 스크립트 언어 강의를 보고 개인적으로 공부하기 위해 정리한 내용입니다.


해당 강의는 아래의 링크에서 보실 수 있습니다.



https://www.youtube.com/watch?v=kejG9xQCKDI





비트코인의 거래란?


복식기입법(Double-Entry Bookkeeping)으로서의 거래


항상 Input과 Output이 있고 총 Input 값의 합은 항상 총 Output값의 합보다 커야한다. 두 값의 차이는 채굴자에게 부여되는 수수료이다.




거래의 체인


UTXO 기반 거래에 대한 설명...




거래 데이터


version


vin = Input값들에 대한 Array


vout = Output값들에 대한 Array




거래의 출력값


비트코인 블록체인의 기본단위, 불가분(indivisible), 블록체인에 기록, 정당성 인정


비트코인 full-node는 모든 UTXO를 Tracking함


"value" : 비트코인의 양


"ScriptPubKey"(locking script) : 출력값을 사용할 수 있는 조건을 명시한 스크립트(i.e. 암호학적 퍼즐 cryptographic puzzle), 누가 쓸수있느냐에 대한 조건을 명시하고 있다. 일반적으로 수신자의 Private Key로 풀수 있다.


모든 거래는 UTXO set을 변화시킴 (state transition)


"비트코인을 받는다" = "자신의 키로 통제 가능한 UTXO가 블록체인에 기록된다."


나의 잔고(balance) = 수많은 블록에 포함된 수많은 거래들에 흩어져 있는 내가 사용할 수 있는 UTXO들의 합




거래 입력값


- "txid" : 사용할 UTXO를 포함하는 거래의 아이디, 모든 Transaction은 이전의 Transaction ID를 Reference를 한다.


- "vout"(Output index) : 사용할 UTXO의 index, 이전 Transaction ID를 보고 이전의 Transaction에서 몇번째 Output인지 나타냄


- "scriptSig"(Unlocking Script): UTXO를 사용하기 위한 조건을 충족하는 스크립트, 이전의 Locking Script와는 반대의 개념 (e.g. 전자서명)


- "sequence"


- 거래 입력값에는 UTXO에 대한 reference만이 존재 -> UTXO의 value와 locking script에 대한 정보가 없다.


- 거래의 검증, 수수료




거래 수수료


- 거래 수수료 (transaction fee) = 입력값의 합 - 출력값의 합


- 거래 수수료는 1. 채굴자에 대한 보상, 2. 스팸 공격으로부터 네트워크를 방어하기 위한 수단으로 사용


- 거래 수수료는 거래금액이 아닌 거래의 크기(kB)에 비례 (e.g. 240 satoshi/byte)


- 시장원리에 따라 거래 수수료가 정해짐


- 초기에는 공간이 널널하였기 때문에 constant fee였지만 -> 거래가 많아지고 활성화 되면서 dynamic fee로 바뀜 (third party fee estimation service or built-in fee estimation algorithm, 자신의 거래에 대한 적정한 수수료 예측 알고리즘)




스크립트 언어


- 포스(Forth, 1960년대 개발된 나온 low level에 script언어)와 같은 스택기반(Stack-based)의 스크립트 언어 사용


- UTXO의 locking script(내가 이 script를 푸는 사람에게 권한을 준다.)와 입력값의 unlocking script(내가 script를 풀었으니 권한을 획득할 수 있다.) 모두 스크립트 언어로 작성


- 튜링 불완전 (no loops, 루프를 돌릴 수 없다. or complex flex control)


- stateless verification




Unlocking script + locking script


Unlocking script : 2 (열쇠)


locking script: : 3 OP_ADD 5 OP_EQUAL (자물쇠, 어떤 숫자에 3을 더했더니 5와 같아지는 숫자)


verification: 2 3 OP_ADD 5 OP_EQUAL 


이 검증 작업을 풀면 아래와 같다.


위와같이 스택으로 verification이 검증된다.


실제 Unlocking Script와 Locking Script의 구조는 다음과 같다.



Unlocking Script는 주로 "scriptSig" 라고 많이 부르는데 주로 signature와 Public Key로 구성되어 있다. Locking Script는 "scriptPubKey" 라고 주로 한다. 


이것을 Execution Pointer에 의해 실행되는 모습을 나타내면 다음과 같다.






거래 만들기


- 지갑이 특정 거래에 맞춰 입력, 출력값들을 선택하여 거래(transaction)를 build함 (오프라인에서도 가능)


- 지갑은 특정 주소가 사용 가능한 모든 출력값 (output)을 계속해서 추적 (track)  (내 잔고를 계속해서 업데이트)


- Full-node client를 돌리는 지갑의 경우 블록체인에 기록된 모든 UTXO들을 저장 -> 거래 입력값 선택 및 신규 거래의 검증이 빠름

- "lightweight" client의 경우 API를 통해 full-node로부터 필요 정보를 수신 (SPV, simple payment verification)


- 특정 주소의 UTXO set에서 거래금액에 맞는 적절한 입력값의 조합을 찾아냄


- 출력값은 스크립트(script)의 형태로 성성, 해당 스크립트에 대한 solution을 제시하여야 해당 출력값의 금액을 사용 가능(e.g 특정 출력값은 Bob의 public address에 대응하는 key를 제시한 경우에만 사용 가능)


- 수수료(transaction fee)의 설정 (i.e. 수수료 = 입력값의 합 - 출력값의 합)

 



거래를 블록체인에 추가하기


- 완성된 거래(transaction)을 비트코인의 P2P 네트워크에 전송


- 비트코인 노드: 비트코인의 프로토콜을 사용하여 비트코인 네트워크에 참가하는 시스템


- 비트코인 노드는 다수의 다른 노드들과 연결되어 있으며 새로운 정당한(valid) 거래를 수신하는 즉시 연결된 다른 노드들에게 해당 거래를 전파 (i.e. gossip network, flooding)


- 해당 거래가 채굴자(miner)에게 전파되어 (mining)되면 블록체인에 추가됨.


- confirm은 내 거래가 블록체인에 추가되면 1 confirm이고 뒤에 블록이 생기면 2 confirm 계속 증가... 6 confirmation은 6 confirm이 되면 double spending으로부터 안전하다는 공식 








리플에 대해 공부를 해보려고 하는데 Blockchainers에서 강의한 내용을 참고하여 정리를 해보도록 한다.


( https://www.youtube.com/watch?v=KEdqYNp5jnU 에서 해당 강의 영상을 보실 수 있습니다.)





4. 리플 합의 알고리즘과 단점




분산 결제 시스템이 가지는 문제: 비잔틴 장군 문제



○ 비잔틴 장군 문제란?


비잔틴 제국 장군들의 딜레마는 1982년 레슬리 램포트 등 3명의 컴퓨터 공학자들이 마이크로소프트 의뢰를 받아 수행한 연구의 논문 발표를 통해 처음으로 정식화 되었다. 비잔틴 제국 장군들이 봉착한 딜레마는 실제 역사적 사건이 아니라 분산 컴퓨팅에서 발생할 수 있는 신뢰와 합의의 문제를 함축한 우화다.


내용은 다음과 같다. 


1. 비잔틴 군대의 여러 사단이 적군의 도시 바깥에 진을 치고 있다.


2. 각 사단은 장군이 통솔하고 있다.


3. 장군들은 오로지 전령을 통해서만 서로 연락할 수 있다. 적군을 관측한 다음, 그들은 공동의 행동계획에 결정해야 한다.


4. 그렇지만, 장군들 가운데에는 배신자가 섞여 있을 수도 있고, 그들은 다른 장군들이 협의에 이르지 못하게 하려 한다.


5. 배신자는 규칙을 충실히 따르는 충직한 지휘관들과 달리 규칙에 얽매이지 않고 마음대로 행동할 수 있다.


Q. 이 때 배신자의 존재에도 불구하고 지휘관들이 동일한 공격 계획을 세우기 위해선 충직한 지휘관이 얼마 있어야 하며, 이 지휘관들이 어떤 규칙을 따라 교신해야 하는지에 대한 문제가 비잔티움 장군 문제다.


다수의 노드(PC)들이 참여하는 분산 네트워크에서 합의와 의사결정은 핵심적인 문제였다. 이 문제를 비트코인은 POW를 사용하여 해결하였다.

처음엔 누가 배신자(중복 사용)인지 모른 채 노드들은 채굴에 나선다. 그러나 다수의 노드가 참여한 블록에서 먼저 채굴이 이뤄지고 결국 배신자인 중복으로 사용된 거래는 자동 폐기된다.  과반수의 충성스럽고 정직한 장군들이 협업(채굴)하면 거짓 정보는 자연스럽게 소멸하는 셈이다.


부정한 세력이 비트코인 네트워크에 참여하는 전체 컴퓨터의 51%를 제어한다면 거짓 정보를 만들 수 있다. 그러나 비트코인 네트워크의 아주 초기 단계에서나 가능할지 몰라도 네트워크가 커지면 커질수록 어렵게 된다. 사토시 나카모토도 논문에서 “이런 상황을 예상할 수는 있지만, 부정한 세력이 그렇게 할만한 유인이 없다”고 밝히고 있다.



○ 비잔틴 장군 문제에 대한 해결 분야 3가지


1. 정확성(Correctness)


- 거래가 정상인지 비정상인지 판별하는 작업으로써 과거에는 기관간 신뢰와 암호화 서명을 통해서 특정 기관에서 한 서명이란 것을 증명하였다.


2. 동의(Agreement)


- 탈중앙화 회계 시스템은 단일 글로벌 사실에 동의할 수 있는가?

- 정확성과 동의는 다른 문제이다. 이에 대한 대표적인 문제가 이중 지불 문제이다. A가 같은 화폐를 B와 C에게 보낼 때 이 거래는 정확성 측면에서 본다면 정상적인 거래이다. 하지만 동의 측면에서 이 두 거래를 모두 동의하면 안되는 문제이다.


3. 실용성(Utility)


- 속도(빠른 네트워크 속도(latency)로 Data를 전송하고 수신), 정확성과 합의에 참여하기 위한 연산능력(채굴에 얼마나 많은 사람들이 참여할 수 있는지) 또는 네트워크를 원활히 사용하기 위해 사용자가(end user) 갖춰야 하는 기술력(낮은 사양에서도 정상적으로 사용할 수 있는지)을 말한다.



리플 프로토콜의 개별 요소


- 합의 (Consensus) = 정확성 + 동의 + 실용성 :  이 3가지가 갖추어져야 합의로 인정된다.


- 서버 (Server): 클라이언트 : 클라이언트 소프트웨어가 아닌 서버 소프트웨어를 실행하는 주체, 합의에 참여


- 원장 (ledger): 합의 과정을 거친 거래로 지속적으로 업데이트 되는 네트워크에 기록된다. 


- Last-Closed Ledger: 합의 과정을 거친 최신원장; 네트워크의 현 상태를 나타내며 다시 바뀌지 않는다.(리플의 특징으로 이더리움의 State와 비슷한 개념으로 생각할 수 있다.)


- Open Ledger: 노드의 현 운영상태 (각 노드마다 Open Ledger를 유지한다); 특정 서버 사용자의 결제는 그 서버 Open Ledger에 적용은 되나 합의 절차 전 까지 거래는 Final하지 않고 합의가 이루어지는 시점에 Open Ledger -> Last-closed Ledger 가 된다.


- Unique Node List(UNL): 각 서버 S는 UNL을 가지고 잇고 UNL은 S가 합의를 할 때 Query하여 합의가 가능한지 합의를 같이하는 S가 신뢰하는 서버들이다. 합의를 도출하기 위해 S의 UNL만 고려되며(네트워크의 모든 노드 X); UNL은 S가 네트워크 안에서 공모하지 않을 것이라고 신뢰하는 집합이다.(S는 UNL각 멤버를 신뢰할 필요는 없다. 여러 멤버들이 모여있는 멤버 집합을 신뢰하는 것이다.)


- Proposer: 합의 절차에 포함되기 위해 모든 서버는 거래를 전파할 수 있으며 새 합의 라운드가 시작되면 모든 서버는 유효한 거래를 포함하기 위해 노력한다. 하지만 S는 합의 과정에서 S의 UNL에 포함된 서버의 Proposal만 고려한다.




기존 합의 알고리즘 ( %는 잘못을 해도 괜찮은 노드의 비율, 비트코인의 경우 51%가 잘못하면 문제가 발생한다.)


- BFT: 33%; 디지털 서명을 요구하지는 않음


- FaB Paxos: 20%


- Attiya, Doyev, Gill: 25%


- BFT-CUP: 33%



리플 합의 알고리즘 (RPCA: Ripple Protocol Consensus Algorithm)


- Byzantine failure이 있더라도 ledger-close에 합의 도달할 수 있다. (모든 거래가 거부되는 합의도 포함한다.)

 UNL에 한 서버가 계속 스팸 Transaction을 발행할 경우 다른 서버들이 해당 서버를 무시하자고 하는 합의도 포함한다.


- 네트워크 각 노드는 그 노드의 UNL의 Probpsal에만 투표를 하지만 (노드별 UNL은 다르다.) UNL membership이 달라도 합의 도달

-> 때문에 fork가 일어나지 않는다. (노드가 2개 이상의 집합으로 나눠지고 각각 합의하고 각 노드 집합의 노드들이 서로 다른 2개 last-closed ledger을 목격하는 것을 fork라고 한다.) 


- 노드 실패율이 20% 이하이면 합의가 가능하다.



RPCA의 1라운드(합의에 도달하기 위하여 진행되는 과정으로 계속해서 라운드가 반복된다.)


1. 각 서버는 이번 합의 라운드가 전에 목격했으나 적용되지 않은 유효한 Tx을 '후보집합'으로 공개한다. 각 서버마다 목격했던 Tx들을 이 거래들을 후보로 추천하고자 공개를 한다.


2. 각 서버는 자신의 UNL에 있는 모든 서버들의 후보집합을 모아서 그 후보집합에 있는 Tx의 유효성에 대한 투표를 진행한다.


3. 최소한의 'yes' 투표(최소한의 기준은 각 round마다 설정이 된다.)를 받은 Tx는 다음 라운드로 진행한다. 받지 못한 Tx는 영구 제외되거나 다음 원장의 합의 과정이 시작될 때 후보로 포함된다.


4. 1,2,3번 과정이 반복되어 계속 진행되다가 UNL상의 서버들의 최소 80%가 Tx에 대해 동의를 한다면 원장에 기록되고 이는 최신 Last-closed ledger가 된다.



정확성(Correctness)


- UNL에서 20% 미만이 Bad하다면 정확하다. 즉, 80%이상이 정상적인 노드일 경우 정확하다.


- UNL은 대부분 신뢰할 수 있는 것이기 때문에 크게 문제가 되지 않고 전체적으로 보면 '공모하는 카르텔'이 문제가 된다. (UNL에서 서버 10개중에 3개가 조작하고자 공모하는 경우)


- 하지만, 이에 따른 Ripple에서 얘기하는 대책은 UNL은 임의적이 아니라 20% 미만으로 유지할 수 있도록 선별한다는 것이다. 즉, 익명이 아니여서 암호학으로 식별할 수 있기에 다양한 대륙, 국가, 산업, 이념 등에서 신뢰할 수 있는 노드 UNL만 선별하면 20%보다 훨씬 적은 확률이 가능하다고 한다. 즉 Ripple은 이론적인 해결책이 아닌 현실적인 해결책으로 접근하였다.




위의 그림은 Ripple Whitepaper에 있는 그림을 가져온 것이다.


옆에 Pc들은 공모할 사람들의 percentage를 나타낸다. X축은 UNL의 크기로 UNL이 몇개가 있는지를 나타낸다. Y축은 카르텔이 합의에 도달하는 가능성, 즉 Fork에 성공할 가능성에 대한 확률을 나타낸다


공모할 사람들이 0.05 퍼센트일 경우(Pc = 0.05), 노란선을 보게되면 Fork에 성공할 가능성은 거의 0%에 가깝게 된다.

표에서 공모할 사람들이 가장 많은 20 퍼센트인 경우(Pc = 0.20), 파란색 선을 보게되면 UNL Size가 10에서는 약 35%이고 UNL Size가 증가할 수록 확률은 증가한다. 하지만 결정적으로 50%의 확률을 넘지 못한다. 50%의 확률이 넘어야 합의에 도달할 수 있기 때문에 안전하다고 주장한다.




동의(Agreement)


- 정직하고 Error-free한 노드들(Non-faulty)이 UNL과 상관없이 동일한 거래집합에 대해 합의를 볼 수 있다.


- 만약 UNL 멤버쉽에 다른 제한이 없고 악의적인 UNL들의 수가 전체 UNL의 20%라면 fork는 가능하다.


- 파벌이 덜 하다면 즉, 각 서버들의 UNL의 교집합이 적다면, 모든 노드 UNL topography가 더 복잡하기 때문에 fork는 더 힘들어진다.


- 동의는 노드 교차점 크기와 연관이 있고 Non-faulty 노드 교차점과는 연관이 없다. 아래에 그림에 설명이 나와있다.



그림을 보면 왼쪽 위의 육각형의 UNL clique(파벌) 부분을 보면 각 노드는 5명을 신뢰하고 있다. 이 육각형에서 한 노드를 보면 붉은색의 다른 UNL clique와 연결되어 있다. 즉, 해당 노드는 다른 UNL Clique에 있는 노드까지 포함하여 총 6개의 UNL을 가지고 있다. 이렇게 다른 UNL Clique와 연결되어 있는 노드를 교차점이라고 한다. 


교차하는 노드가 Faulty한지 Non-Faulty한지는 중요하지 않고 교차하는 노드의 수가 많은지가 중요하다고 한다.






실용성(Utility)


- 정확성과 동의가 보장 된다면 네트워크 속도만 보장이 됐을 때 Convergence는 보장된다. 노드 반응시간을 모니터 하고 특정 시간보다 반응이 느린 노드는 모든 UNL에서 제외된다.


- 모든 노드의 초기 UNL이 조건(각각의 노드들은 처음부터 UNL을 가지고 시작한다.)을 충족하다가 특정 Node가 반응이 느리거나 없어 제외된다면 새로운 UNL로 정확성과 동의가 충족 되어야 한다.


- "A latency bound heuristic is enforced on all nodes in the Ripple Network to guarantee that the consensus algorithm will converge"


- 노드가 악의적인 행동을 한다면 네트워크에서 제외(악의적인 행동의 예: 매 거래마다 'no' 투표, 합의에 의해 검증되지 않는 거래를 지속적으로 제안)


- 기본적으로 큐레이션된 UNL을 모든 유저에게 제공해서 공모하는 확률을 낮춘다. 순진한 유저도 합의 알고리즘에 참여 가능


- 포크를 예방하기 위해 네트워크 분열 탐지 알고리즘 사용. 노드는 UNL에 활성화된 멤버 수를 모니터 하고 만약 수가 급격하게 정해진 수치 이하로 떨어진다면 포크가 발생했을 가능성이 크다. 이런 경우 노드는 Tx를 처리하거나 투표는 안해도 참여하고 있다는 것을 'partial validation'으로 표시


- RPCA는 합의 라운드에 적용되지 않고 합의 최소 기준점이 최대 80%까지 증가하는데에 적용. 수 라운드를 통해 네트워크 거래률을 저하하는 노드 탐지가 가능하다. 이런 불량 노드는 첫 몇 라운드는 괜찮지만 합의 기준점이 증가함에 따라 제외된다. 80%에 해당되는 Tx는 의외로 몇개 없어 느린 노드도 합의를 볼 수 있을 수 있음.


- 블록 생성시간은 수 초이다.




문제점 및 지적(리플의 문제점을 다룬 논문과 비트코인 core개발자가 Ripple의 코드 및 구조를 보고 문제점 지적한 내용이 주로 있음)


- SCP 이전 Stellar 대 RPCA


- Validator UNL 교집합이 최대 UNL 교집합 40%가 (과거 20%)되어야지 Fork가 없음


- 리플 기술 문서는 따로 '블록체인'을 언급 하지 않음; '블록의 체인' - 왜 각 블록이 특별한가? 


- 서명된 메시지 자체는 임의적으로 만들면 되기에 신뢰대상이 되지 않음. 리플의 신뢰는 UNL과 서명된 메시지가 일치하기 때문이다. 리플은 reorg가 없을 것이라고 가정하는 듯 하다. reorg 위험이 없다면 이는 중앙화 시스템이 아닌가?


- 리플 현재 UNL 교차점은 100%이지만 자원하는 사람이 없다. (UNL 8개에서 더 이상 증가하지 않는다. Validator역할에 대해 보상도 없으며 법적 책임을 가져야 하기 때문에 아무도 하려고 하지 않는다. )


- 비트코인: 경제적 합의. 허가없이 경제적 유인 때문에 채굴자가 된다.

- 리플: 경제적 유인 없음. Validator이라는 이유로 UNL에 자동 포함 되지 않고 UNL에 포함이 되기 위해 리플에 문의를 하고 허가를 받아야 함. Validator는 각종 법적 책임을 쳐야함(태만에 의한 소송, 금융 범죄 방조) 


- 만약 리플에 포크가 발생한다면 이중 지불 및 금전적 피해가 발생할 것이며 진 체인은 기록 일부 또는 모든 기록을 포기해야 함 - 리플 소프트웨어는 이게 불가능 하다고 가정. 만약 발생한다면 바로 소송


- UNL 기록이 100% 교차하는 것이 교차 하지 않는 것에 비해 유리. 그럼 누가 왜 100+ 개의 고유 노드나 UNL을 사용할까? 

결론은 사용하지 않는다.


- KYC/ AML (리플은 거의 실명제)


- 리플은 모든 validator는 원장을 가지고 있어야 한다 - 확장성 문제


- 만약 거래기록을 가지고 있기에 법적 책임을 져야 한다면 은행이 왜 서로를 위해 Validator가 될까? 


- 중앙화 시스템이 가지고 있는 문제 및 공격 vector


- XRP는 스팸 공격 대비해 존재하나 스팸 공격은 악의가 없다는 식으로 진행 될 수 있다. 리플회사가 이와 같은 경우 XRP를 팔지 않을 경제적 유인은 없다. 스팸공격에도 결국 XRP가 필요하고 공격시 XRP를 태우기 때문에 결국 XRP의 가격이 올라가기 때문이다.




질문


- 이론 vs 실천, 시행착오의 역할, Open source VS Closed source


-> 이론상에서 좋은것이 반드시 실천에서 승리하는 것은 아니다. 실패 후에 잘될 수 있기 때문에 시행착오를 거치면서 강화될 때 Open Source가 좋은지 Closed source가 좋은지.(비트코인은 Open source, 리플은 Closed source)


- 중앙화 - 분산화 - 탈중앙화?


-> 리플은 조직 자체는 중앙화에 가깝다.



- 가치 이전 VS 자산이전


-> 비트코인은 실제로 BTC가 옮겨지지만 XRP는 가치를 이전하기 위한 수수료 같은 개념 



- 리플의 첫 의도 및 방향성과 현재 의도 및 방향성


-> 개인에게 가치이전할 수 있는 방향성을 주려고 하였으나 방향성이 바뀌어서 은행에서 사용하는 방향으로 변경되었다.



- 역사적 시선으로 XRP 바라보기(사기체인)


-> 역사적으로 개발자들이 ICO를 진행하면서 모든 코인을 풀지 않고 숨겨두었다가 ICO후 가격이 오르면 팔아서 이익을 챙기는 일이 많았는데 때문에 리플은 XRP를 내세우지 않았다.



- 규제와 Bitcoin-neutrality


-> Bitcoin-neutrality(비트코인 중립성): 비트코인은 화폐라고 정의하면 다른 용도로 사용하는 비트코인에 다른 사용 방법들은 제외가 된다. (Internet-neutrality: 인터넷은 메일을 위한 시스템이라고 정의하면 인터넷은 발전하지 못했다.)


- 블록체인의 정의


리플에 대해 공부를 해보려고 하는데 Blockchainers에서 강의한 내용을 참고하여 정리를 해보도록 한다.


( https://www.youtube.com/watch?v=lTOt2-YA_w4 에서 해당 강의 영상을 보실 수 있습니다.)





3. 리플 핵심 기능



기능 1. 노드별 역할에 따른 기능


○ Ripple 노드가 할 수 있는 역할


1. Users : 유저로써 결제를 받거나 하는 역할을 수행한다.


2. Market makers : Trade Enabler, 자산의 거래를 가능하게 할 수 있는 역할로써 Gateway도 이 역할을 담당한다.


3. Validating servers : 시스템에서 발생하는 모든 거래 내역 검증을 하기 위해 합의 프로토콜 실행하는 역할로써 비트코인같은 경우에는 Miner가 담당하는 부분이다.




기능 2. 결제 Path finding / Matchmaking System.


○ 결제하는 방법


1. XRP를 사용 : 거래를 암호학적으로 서명하여 실제로 토큰이 사용되는 방법이다.


2. XRP를 사용하지 않는 non-XRP : 하왈라 시스템이나 리플이 가고자 하는 방향과 비슷하다. 결제는 강요할 수 없으며 IOU/ 재매입 계약서를 기록하는 방식과 비슷해진다(분산 신용 시스템). - IOU는 기본 기축통화인 달러의 속도제약을 극복하기 위해 사용한다. 


- 그렇다면 IOU란 무엇인가? IOU는 " I OWE YOU" 라는 발음을 약자로 일종의 빚을 진다는 뜻이다.



○ 위의 그림은 A가 B에게 $100를 non-XRP로 전송하는 그림이다. 위의 그림에서 Trust라고 되어있는 것은 신뢰 관계를 나타내는 것으로 U1은 A에게 최대$250 만큼의 신뢰를 주는 것이다. 따라서 이 신뢰 관계를 따라 가면서 거래가 진행되어 최종적으로 A-> U1 -> U2 -> U4 -> B 의 순서로 송금이 이루어진다. 이 신용 최대 한도까지 거래가 이루어질 수 있기 때문에 U1 -> U3로 $100 전송은 불가능하다. 


○ 따라서 Ripple은 결국, 결제 Pathfinding / Matchmaking System이다. Trustline, 지불 경로는 시스템에서 즉각적으로 판단이 가능하여 거래 가능여부가 바로 결정된다.


○ 만약 신용라인이 최대한도에 달했다면 즉 위의 그림에서 A가 U1에게 이미 $250 만큼을 IOU한 상태라면 다른 네트워크에서 자유롭게 거래를 하지 못한다. (상실 제한 및 책임 한도)


○ 따라서 신뢰측면에서 항상 본인이 신뢰할만 하다고 판단하는 대상을 선택하여야 한다.


○ 내가 신뢰하지 않기로 결정한 대상 때문에 돈을 잃을 수는 없지만 내가 신뢰하는 대상에게서는 신뢰를 잃는 것이 가능하다.

이 말은 내가 신뢰하지 않는 사람이 나에게 100만원을 빌려달라 할 경우 돈을 빌려주지 않기 때문에 돈을 잃는 일은 없지만 신뢰하는 사람이 100만원 을 빌려달라고 하여 빌려주고 빌린사람이 갚지 않는 경우 나와 그 사람의 신뢰관계가 악화된다. 이것을 보면 실제 세상과 흡사한 구조같다.


○ 환전은 즉각적이지 않을 수 있다. 이 말은 환전을 하기위해서는 게이트웨이를 거쳐야 하는데 이 게이트 웨이는 수요와 공급에 따라 환율을 설정한다. 따라서 환전하기 위해 게이트웨이의 설정을 받아들이면 환전이 가능하지만 받아 들이지 않으면 환전이 되지 않는다. 


○ 그렇다면 왜 굳이 XRP를 사용하여야 하는가? 라는 질문이 생길 수 있다. 굳이 XRP를 사용하지 않아도 거래는 가능하지만 유동성 측면에서는 XRP가 도움이 된다. 전혀 연결이 없는 곳끼리 서로 환전을 하는 경우 XRP를 사용하면 실제 현물이 거래되기 때문에 이러한 XRP가 신뢰역할을 해주기 때문에 거래를 더 빠르게 할 수 있다.




기능 3. 내가 가지고 있는 어떠한 가치를 원하는 어떠한 가치로 누구에게나 전송이 가능하게 하는 프로토콜


○ 리플은 결국 거래하고자 하는 화폐에 대해 선택의 자유를 가능하게 한다. 기본적으로 가치와 가치를 거래하고 가치의 종류는 본인이 선택할 수 있기 때문이다. 


○ 비트코인의 결제속도인 1시간에 비해 빠른 결제속도를 가지고 있다. 


○ 대다수 결제 input은 한 계좌로 제한된다(가명이지만 1인당 1계좌로 제한). 만약 신분을 숨기면 할 수 있는 기능이 제한적이다. 

- 예를 들면, 만약 내가 가지고 있는 XRP를 USD로 환전을 하고 싶은 경우 은행의 Gateway를 거쳐야 한다고 할 경우 은행에서 나의 개인정보를 요구한다면 익명성 기능은 제한될 수 밖에 없다. 




결론. 탈중앙화가 아닌 중앙화 시스템.


○ 결론적으로 결국 Ripple은 중앙화이다. 

- 대다수 Validating 서버는 리플회사가 관리한다. 다른 사람이 운영하는 서버도 있으나 기본 목록에 있는 서버는 모두 리플 회사의 서버이다. 또한 이 Ripple 시스템에서 발생하는 모든 거래 보안은 리플 회사의 책임이다. 즉, 탈중앙화가 아닌 중앙화 환경이라 볼 수 있다.



리플에 대해 공부를 해보려고 하는데 Blockchainers에서 강의한 내용을 참고하여 정리를 해보도록 한다.


( https://www.youtube.com/watch?v=lTOt2-YA_w4 에서 해당 강의 영상을 보실 수 있습니다.)





2. 리플 핵심 개념



○ Ripplepay의 실패 원인


- 1. 아예 모르는 다른 유저와 나 사이 신용 라인이 생성이 불가능하다. 참여를 하기 위해서는 기존 네트워크에 지인이 있어야 하기 때문에 고립되어 따로 노는 소규모 커뮤니티로 발전하지 못하였다.


- 2. 소프트웨어 자체는 중앙화, 신용 라인과 잔고를 기록하는 장부는 여전히 중앙 통제됨



○ Ripple의 해결책


- 1. XRP. BTC와 흡사하게 주소에서 다른 주소로 송금 가능. 신뢰 네트워크 일원이 아니여도 송금이 가능하다. 환전은 내장되어 있는 탈중앙화 가치 교환 절차를 통해 가능. 가치 교환은 장부의 일부임


- 2. 게이트웨이. 희박한 유저 문제 해결. 일종의 허브로 서로 연결하여 기존 리플을 사용하는 사용자를 모를 때 사용할 수 있고 신용 중개인 역할 맡는 상업 서비스 + 지인을 통해 연결하기 보다는 전문 상업 서비스로 연결되기를 선호할 때 사용. 사용자가 돈을 보낼 때 사용자와 받는 사람 사이 신뢰 체인의 첫 연결고리 및 돈을 받을 때 마지막 연결고리. 사용자는 동시에 다수 게이트웨이 신뢰 가능. 채굴장과 비슷한 탈중앙화 유지. 게이트웨이 자격 요건은 없음. 리플 프로토콜은 다양한 네트워크 토폴리지의 연결성 수용가능(현대 중앙 은행부터 P2P 체계까지). 초기에는 게이트웨이에 의존. 하지만 시장 점유율이 증가하면서 오리지널 리플 프로젝트의 P2P 구조로 변경



○ 특징 및 문제점


1. 게이트웨이 : 신뢰된 3자를 믿어야 하기에 채무불이행을 방지 가능한 방법이 없음 (Counterparty Risk). 암호학으로 신뢰 문제 해결책을 제시하지 않음


2. XRP : XRP는 스팸방지를 위해 만들어진 수수료이고 거래시 Burn됨. 수수료가 없을 경우 사람들이 마구 거래를 진행하면 네트워크에 무리가 발생할 수 있다. 때문에 Paypal과 동일하게 거래는 수수료를 요구함. Burn된 수수료를 통해 Ripple사가 보유한 XRP 가치가 상승. Ripple사가 발행인이기에 발행량/ 시기를 자유자재로 결정. 프로젝트 자금 제공을 위해 만들어 졌으나 개발자 신뢰 저하. 1000억개에서 시작, 이후 디플레이션


3. 합의 : 작업 증명이나 채굴 없이 합의가 이루어짐. 체인분할과 노드 Sybil 공격을 방지하기 위해 Unique Node List (UNL) 제공. 개인 노드가 Byzantine해서 이중지불을 시도하더라도 공모해서 다수 합의 이상을 보지 않을 노드. 이상적으로는 대기업, 다양한 커뮤니티 멤버, 게이트웨이와 다양한 비영리 단체가 이에 포함. 페북 함께 아는 친구와 동일. UNL이 연결되어 있는 이상 합의에 신속히 도달(BTC 확장성 및 거래 속도와 상반)

-> 8 개 이상 제공되지 않고 추가적 UNL은 없고 경제적 유인도 없음.



○ Ripple이 우리에게 제시하는 질문


- 게이트웨이가 있다면 어떠한 가치도 거래 및 교환 가능 (USD, 10센트, 항공사 마일리지, BTC 등) = > 가치란 무엇인가?


- 리플이 강조하는 자유로운 자산의 유동성은 중요한가?


- 중앙화 -> 탈중앙화는 가능한가? 탈중앙화란 무엇인가? 사용자에게 이게 중요한가? 한번에 바뀌는가 점차 바뀌는가?


- 우리는 왜 암호화 화폐를 사용하는가? (자유, 프라이버시, 암호학이 보장하는 보안, 낮은 수수료, 국경을 초월, Trustless(비신뢰성), Censorship-free(검열에서 자유로움), Permissionless(비허가성) 등)





+ Recent posts