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


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





1. 개요



(1) Ripplepay


○ 2004년 Ryan Fugger에 의해 개발된 하왈라 시스템이다.


- 하왈라 시스템은 아는사람의 아는사람으로 연결되어 있는 일종의 무슬림 P2P네트워크이다. 위의 그림으로 설명한다. 파란선은 신뢰나 정보, 붉은선은 돈을 의미한다.


1 - A라는 사람이 다른 지역에 있는 B에게 돈을 송금하기 위해 X라는 중개인에게 돈을 주고 암호를 알려준다.

2a - A는 B에게 암호를 알려주고 중계인에게서 돈을 가져가라고 한다.

2b - 중계인 X는 해당 지역의 중계인 M에게 B라는 사람이 와서 해당 암호를 얘기하면 얼마를 내어주라고 전달한다.

3a - B는 M에게 가서 암호를 얘기하고 돈을 요구한다.

3b - M은 B에게 돈을 주고 장부에 기록한다. 나중에 X에게 돈을 받는다.


○  이 과정에서 거래 장부만 기록되지 실제 다른 지역에게 현물이 전달되지는 않는다.


○ 탈중앙화(내 지역사람만 믿으면 됨), 확장성 보장(사람이 더 늘어날 수록 확장됨), P2P 신뢰모델(작은 신뢰들이 쌓여서 큰 신뢰를 구축함)이다.


○ SNS처럼 사용자의 수에 따라 성공하는 모델이다.



(2) Ripple


○ Jed McCaleb(eDonkey, Mt.Gox, Stellar), Arthur Britto, David Schwartz, Chris Larsen 4명에 의해 주로 개발


○ 비트코인 같이 채굴에 의한 합의가 아닌 네트워크간 합의에 의한 화폐 시스템


○ 중앙 거래소 의존 감소, 전기 절약, 비트코인보다 빠른 거래속도가 장점이다.


○ RTXP, Ripple Labs, XRP 등으로 은행이 비트코인과 경쟁을 할 수 있도록 하는 도구 및 전자 자산(비트코인과 비교해서 은행의 경쟁성이 너무 없어 보였다고 한다.)


- RTXP : Ripple Transaction Protocol

- Ripple Labs : 회사 이름

- XRP : RTXP 위의 토큰, 실제로 거래되는 화폐를 의미



○ 리플이 해결하고자 하는 문제


- 결제 스택(제일 위에 Application Layer부터 결제가 이루어지는 절차)이 너무 복잡


- 가치가 정보같이 이동할 수 있나?


- 어플레이어


- 인프라는 과거와 동일 (은행을 대체하는 것이 아닌 은행을 위한 내부 플랫폼)


- SWIFT를 탈중앙화로 대체(대표적으로 AirBnB는 2008년 8월 시작된 세계 최대의 숙박 공유 서비스이다. 자신의 방이나 집, 별장 등 사람이 지낼 수 있는 모든 공간을 임대할 수 있다. 실제로 이용자는 자신의 화폐로 지불하고, 제공자에게는 또 환전해서 그 나라의 화폐로 지급해준다. 때문에 1년에 100억원 이상을 이 환전하는 수수료로 소모하고 있다고 한다.)


-인프라 리셋(인프라를 보았을 때 Application Service는 데이터베이스 같이 하위 계층은 너무 노후화 되어있어서 이 하위 계층에서 일어나는 작업을 효율적으로 리셋하고자 한다.)


- Ripple은 무료 Paypal이라고 한다.


○ Ripple의 시사점


- 은행은 미래에 여전히 사라지지 않을 것이고 여전히 힘을 행사할 것인가? (현재는 신뢰받는 제 3자가 필요할 때가 있지만 미래에도 그럴 것 인가?)

- 은행의 가장 큰 라이벌은 BIG 5와 신기술인가?(Google, Microsoft, Facebook, Apple, Amazon의 결제 시스템으로 업무를 진행하기 때문에 은행들이 위협을 받을 수 있다.)

- BIG 5 회사는 결제 시스템을 제공할 것인가? (Apple Pay 등)

- Ripple의 다른 라이벌은 다른 암호 화폐인가? (무료 PayPal)



프라이빗 체인을 개발하고 싶어 찾아보던중 


R3 Corda와 Hyperledger Fabric을 찾을 수 있었다.



그 중 먼저 Hyperledger Fabric을 찾아서 좋은 개발 문서를 찾은 것 같아 오늘은 개발에 대한 글을 작성하고자 한다.



(링크: https://developer.ibm.com/kr/cloud/bluemix/2017/04/04/starting_blockchain_using_hyperledger_fabric/)


실제로 나의 능력내에서 구현이 가능한지에 대해서는 아직 미지수지만 일단은 진행해 보기로 하였다.




링크 글 본문에 나와있는대로 Win10 환경이기 때문에 Docker Toolbox말고 Docker Community를 설치하였고


체인코드 개발을 위한 Golang, 그리고 Virtual Box를 설치하였다.




처음부터 "This computer is running Hyper-V. VirtualBox won't boot a 64bits VM when Hyper-V is activated.  .... " 라는 에러가 발생하여 헤메인 결과


https://jayvilalta.com/blog/2016/04/28/installing-docker-toolbox-on-windows-with-hyper-v-installed/ 


에서 참고하여 Blockchain 생성 명령어를 


docker-machine create -d virtualbox --virtualbox-no-vtx-check blockchain 로 고쳐서 사용하여서 오류는 해결하였지만 아래의 화면에서 진행이 되지않아서



http://www.poweronplatforms.com/enable-disable-hyper-v-windows-10-8/


위의 링크에서 Option 2에 나와있는 PowerShell을 사용해 Hyper-V를 Disable하여 Hyper-V를 완전하게 끄고 다시 진행하였더니 이번에는 아래의 화면처럼 "Waiting for an IP..." 에서 넘어가지 않는다...



헬프...

내용정리 - 블록체인 기술과 보안 고려사항(보안기술연구팀, 2017.08.17)




해당 링크에서 금융보안원에서 나온 '블록체인 기술과 보안 고려사항' 이라는 보고서를 다운받을 수 있습니다. 



본문의 내용은 해당 보고서를 읽고 정리한 내용입니다.




1. 개요


○ 이 보고서는 EU 산하 정보보호기구인 ENISA의 보고서(금융권에서 블록체인 시스템 도입 시 고려해야할 보안 이슈와 보안 강화방안 제시)를 토대로 작성된 보고서로 금융권에서 안전한 블록체인 시스템 도입을 위해 참고 가능한 보안 위협과 이에 대한 대응방안을 제시한 보고서입니다.




2. 금융권 블록체인 도입 시 보안 위협


○ 이 보고서에는 크게 키 관리, 거래 검증 및 합의, 참여자 권한관리, 블록체인 SW보안, 서비스보안으로 총 5가지로 보안 위협을 분류하였고 이에대한 총 12개의 취약점에 대한 정보를 담고있습니다.


1. 키관리 

- 키 도난 및 분실

- 취약한 키 생성


2. 거래 검증 및 합의

- 합의 가로채기

- 사이드 체인 내 비정상 거래 발생


3. 참여자 권한 관리

- 개인정보 침해

- 권한 오남용


4. 블록체인 S/W 보안

- 블록체인 S/W 취약점

- 스마트 컨트랙트 취약점


5. 서비스 보안

- 분산 서비스 거부 공격

- 가용성 저하

- 비정상거래 탐지 불가

- 상호 운용성 미제공


아래의 정리 내용은 본 내용을 옮겨 적지 않고 보고서를 읽고 제가 아는 범위의 지식 내에서 이해한 내용입니다.





1. 키관리



(1) 키 도난 및 분실


○ 이 내용은 사용자의 Private Key가 공격자에 의해 도난되거나 실수로 분실될 경우에 발생하는 문제점에 대한 내용입니다.


○ 참여자는 본인만의 고유한 Private Key를 사용함으로써 예를들어 Transaction을 발행할 때 이를 입증하는 전자서명을 하여 Transaction을 발행하고 증명하는 수단으로 사용합니다.


○ 이 Private Key가 참여자의 단말의 저장소에 저장이 되는데 이 때 Plain Text로 저장이 되거나 서명 같은 작업에 사용된 이후에도 메모리에 남아있는 경우 공격자가 접근이 가능할 수 있습니다.


○ 이렇게 될 경우 공격자에 의해 자산 또는 기밀 거래가 유출이 되는 문제가 발생할 수 있습니다.


○ 또한 참여자가 본인의 Private Key에 대한 접근 권한을 상실하거나 분실한 경우에는 본인의 자산을 사용할 수 없게 되는 문제가 발생할 수 있습니다.


○ 이전에 정리한 메디블록 인터뷰 Q&A중에 이러한 취약점에 대한 문제에 대해 질문하였는데 메디블록 대표분도 이 문제는 모든 블록체인 가상화폐 시스템의 공통 문제이기 때문에 협력하여 추후에 해결방안을 마련해 나가야 할 것 같다고 했던 내용이 있었던 것 같습니다.




(2) 취약한 키 생성



○ Private Key생성 방식이 안전하지 않을 경우 'Key 재생성 공격'을 통해 공격자가 참여자의 Key를 획득할 수 있습니다.


○ 안전하지 않다는 것은 난수 생성 방식의 문제로 공격자가 예측을 통해 참여자의 난수 값을 추측할 수 있는 일이 가능하여 무작위 대입 공격을 통해 키를 재생성하는 공격이 가능한 경우를 말합니다.


○ 또한 당장은 아니지만 양자 컴퓨팅에 의해 무작위 대입공격이 빠르게 이루어져서 공격할 수도 있습니다.


○ 비트코인에서 Private Key 생성에 관한 내용은 Steem의 정리글 링크를 남겨두겠습니다. ( *링크: https://steemit.com/kr/@easyblockchain/2kjjep)




2. 거래 검증 및 합의



(3) 합의 가로채기


○ Public Block Chain에서는 주로 참여자 중 과반수의 동의로 합의를 도출하기 때문에 공격자가 과반수를 장악할 경우 거래 유효성 검증 프로세스를 조작할 수 있습니다.


○ 비트코인 White Paper를 정리하면서 본 51%공격이 바로 이러한 내용인데 정리할 때 51% 공격은 투자비용이 천문학적으로 들어가야 가능하기 때문에 사실상 불가능하다라고 정리하였는데 이 보고서에서는 클라우드 컴퓨팅 등 인프라 확보 비용이 점차 저렴해져서 공격이 현실화될 가능성이 존재하다고 합니다.



(4) 사이드 체인 내 비정상 거래 발생


○ 사이드 체인은 메인체인과 상호연계하여 가상화폐 호한성을 제공하거나 스마트 컨트랙트, 거래 기밀성 등의 추가 기능을 제공하는 블록체인입니다. 링크에 있는 발표자료를 보시면 이해하는데 도움이 될 것 같습니다. (링크: https://steemit.com/kr/@tenihil/9-28)


○  이러한 사이드 체인에 유효하지 않은 자산이 이전되어 거래되거나 중단될 시 메인체인으로 Transaction들을 반영해야 하는데, 이 때 발생하는 메인체인의 부하 문제를 다루고 있습니다.



3. 참여자 권한 관리



(5) 개인정보 침해


○ 이 문제는 Public Block Chain에서 발생하는 문제입니다. 참여자는 본인이 참여하지 않은 거래까지 모든 거래 이력을 다운로드 할 수 있고 이를 통해 거래 추적이 가능하여 개인정보 침해가 발생할 수 있는 문제가 있습니다.


 ○ Private Block Chain의 경우에는 일반적으로 거래정보의 기밀성이 가능하지만 참여자 권한관리가 미흡할 경우 개인정보 침해가 발생할 수 있다고 합니다.


○ Private Block Chain 구성이 가능한 Hyperledger fabric, R3 Corda는 각각 Channel, Notary service 기능을 통해 거래 기밀성을 보장한다고 합니다.


○ 또한 블록체인은 삭제할 수 없기 때문에 '잊혀질 권리' 문제가 발생할 수 있습니다.



(6) 권한 오남용


○ 블록체인은 분산구조이기 때문에 참여자 권한 관리 등의 통제가 모든 참여자에게 일관성 있게 적용되는 것을 보장하기 어렵다고 합니다. 이부분은 Private Block Chain에서 발생할 수 있는 문제인 것 같습니다.


○ 따라서 일관적이지 않은 통제로 인해 권한 오남용이 발생하여 보안사고가 발생할 수 있다고 경고하고 있습니다.




4. 블록체인 S/W 보안



(7) 블록체인 S/W 취약점


○ 이부분에 대해서는 이더리움의 Parity 취약점 사건을 예로 들수 있을 것 같습니다. (링크: https://steemit.com/kr/@ironpark/15-parity)


○ 대부분 S/W는 오픈소스이기 때문에 안전할것이라 생각되지만 알려지지 않은 취약점이 존재할 수 있다고 합니다.


○ 또한 S/W 보안 패치가 분산 구조에서 모든 참여자에게 적용되었음을 보장하기 힘든 부분도 존재합니다.



(8) 스마트 컨트랙트 취약점


○ 스마트 컨트랙트는 개발자의 코딩으로 작성되며 따로 보안성 검증 절차 및 기능은 존재하지 않기 때문에 보안적 결함이 존재할 수 있고 Contract가 복잡할수록 발생 가능성이 높다고 합니다.


- '16.5월 발표된 보고서(P. Vessenes, "Ethereum Contracts are Going to be Candy for Hackers")에 따르면 인터넷에 공개되어 있는 Ethereum Smart Contract 템플릿 코드 중 많은 수에 심각한 취약점이 존재한다고 합니다.


- '16.6월 이더리움 DAO사건이 이 취약점의 예시입니다. (자세한 내용 링크 : http://www.seunghwanhan.com/2016/07/the-dao.html)


5. 서비스 보안



(9) 분산 서비스 거부(DDoS) 공격


○ 공격자는 블록체인의 분산된 노드를 통해 블록체인 네트워크에 대량의 스팸거래를 발생시켜 거래 유효성 검사 시간을 지연시켜 블록체인 전체에 대한 DDoS공격을 수행할 수 있습니다.


- 실제로 '16.3월 평균보다 높은 수수료를 제시한 대량의 스팸거래로 인해 비트코인 서비스가 거의 중단되었다고 합니다.


- 수수료를 높게 제시하면 우선적으로 포함되기 때문에 평균 적인 수수료를 제시한 정상거래들은 DDoS 현상이 발생하는 원리입니다. 이후 비트코인 채굴자는 비정산적으로 높은 거래 수수료를 제시하는 거래같이 의심되는 거래에 대해 우선순위를 낮추어서 유사한 공격에 대응하였습니다.


○ 또한 DDoS 공격을 위한 스팸거래 요청은 악성코드에 감염된 참여자에 의해 발생할 수 있으며 분산구조로 인해 전체 참여자에 대한 악성코드 감염 여부 확인 등 대응이 어렵습니다.


○ Private Block Chain의 경우 의심 거래를 발생시키는 참여자를 네트워크에서 차단하는 등의 조치가 가능하지만 공격자가 많은 노드를 장악할 경우 여전히 DDoS 공격이 가능합니다.



(10) 가용성 저하


○ 블록체인 참여자가 급증하여 Transaction 수도 많아지고 누적도 많이 쌓이게 되면 이후에 새로운 Transaction이 추가되는데 더 많은 시간과 관리 비용이 증가하여 가용성이 저하된다는 설명입니다.


- Full Node를 보관하고 관리하여야 하는 금융회사는 거래 정보량이 급격하게 늘어나게되면 이에 따른 추가 서비스 확대가 제한적일 수 있습니다.


- 또한 과반수의 동의를 얻는 과정에서 과반수가 점점 커지기 때문에 노드가 늘어날 수록 새로운 Transaction에 대한 처리시간이 증가할 수밖에 없을 것이고 이에따른 서비스 개발도 제한적으로 될 것이라고 설명되어 있습니다.


(11) 비정상 거래 탐지 불가


○ Public Block Chain의 경우 참여자의 익명성으로 인해 거래자 식별이 불가능하기 때문에 사기거래, 자금세탁 및 테러자금 조달등의 비정상거래를 탐지해내기 어렵습니다.


○ 거래소에서 환전을 위해 자신의 은행계좌 사용하기 때문에 이 계좌를 추적하는 것은 가능하지만 거래가 발생하는 것을 사전에 차단하기는 어렵습니다.


○ 또한 금융 사기 및 고객 실수로 인한 비정상거래에 대해 거래의 유효성을 입증받아 처리될 경우 다시 복구하기 어렵습니다.


○ 이외에도 다음과 같은 비정상거래등이 존재합니다.


- 이중지불 : 자신이 지불한 대가를 거래가 성립되고 나서 다시 되돌리거나 사용한 대가를 재활용하는 방법


- 유출된 Key 서명 : 공격자에 의해 Key가 유출된 정상 참여자의 키로 서명된 거래


- 정책 미준수 거래 : 서비스 정책에 어긋난 거래로서 프라이빗 블록체인에서 참여자가 허가받지 않은 서비스에 대하여 거래를 요청한 경우에 해당


(12) 상호운용성 미제공


○ 블록체인 간 자산이전, 기능 확장, 연계 서비스 개발 시 블록체인 간 호환성이 요구되거나 상호운용성이 제공되지 않아 예상치 못한 보안 위협이 발생가능하다고 하는데 아마 이부분은 사이드체인에서 발생할 수 있는 문제점과 유사한 것 같습니다.


○ 블록체인별 서로 다른 지갑 S/W 사용에 따른 호환되지 않는 키 생성 알고리즘, 거래 요청 및 통신 프로토콜등이 존재하며 표준 지갑 규격이 개발되고 논의되어야 할 것입니다.





비트코인 White Paper 정독 해보기


나카모토 사토시(Satoshi Nakamoto)의 "Bitcoin : A Peer-to-Peer Electronic Cash System" 을 읽고 이를 정리해보았습니다.


아직은 영문논문을 그대로 번역하며 읽기는 무리여서 한글 번역본을 읽었습니다. 한글 번역본 링크는 아래에 적어두었습니다.


https://encodent.com/bitcoin


또한 저도 비트코인의 원리와 작동방식은 이전에 공부하여 알고는 있었지만 이렇게 White Paper를 직접 읽고 무슨 말인지 해석하는데 어려움이 있어서 Steem에서 저보다 먼저 White Paper를 읽고 해설해주신 분의 글을 같이 읽으며 참고하여 작성하였고 많은 도움을 얻을 수 있었습니다. 링크납깁니다.


https://steemit.com/kr/@feyee95/4grqyf


아래의 글은 White Paper를 한 문단씩 정독하며 제가 생각하는 중요한 내용을 문단 아래에 기술하였습니다. 


그럼 지금부터 정독답게 서론부터 읽도록 하겠습니다.




1. 서론


인터넷 기반 상거래는 전자 결제를 처리할 신뢰받는 제3자 역할을 거의 전적으로 금융기관에 의존해 왔다. 이 시스템은 대다수 거래에 충분히 잘 동작하지만, 여전히 신뢰 기반 모델의 태생적 약점을 극복하지 못한다. 금융 기관은 분쟁 중재를 피할 수 없기에, 완전한 철회불가 거래는 실제로 가능하지 않다. 중재 비용은 거래 비용을 높이고, 실거래 최소 규모를 제한하며 소소한 일상적 거래 가능성을 가로막고, 철회불가 서비스를 위한 철회불가 결제 능력의 상실에서 더 큰 비용이 발생한다. 철회가능성을 위해 신뢰 확산이 요구된다. 상거래자 (Merchants)는 필요 수준보다 더 많은 정보를 위해 그들을 괴롭히는 고객을 경계해야 한다. 사기의 일정 비율은 불가피한 것으로 간주된다. 이런 비용과 결제 불확실성은 직접 물리적 통화(currency)를 사용시 회피될 수 있지만, 신뢰(받는 제3)자 없이 통신채널로 결제를 수행할 방법은 존재하지 않는다.


여기서는 기존의 전자결제의 문제점을 기술하고 있는데 그 내용은 "신뢰받는 제 3자 기반" 입니다. 주로 신뢰받는 제 3자의 역할을 담당하고 있는 곳은 금융기관입니다. 여기서 말하는 분쟁 중재는 거래를 진행하면서 거래자들 사이에 발생할 수 있는 분쟁들을 금융기관이 중재 해주어야 하고 중재 비용은 가령 내 계좌에서 돈을 송금하거나 인출할 때 수수료가 발생하는 내용으로 해석하였습니다. 이러한 중재 비용이 불가피 하다는 문제점 때문에 거래 비용이 증가하고 100원, 200원 같은 작은 금액은 거래하기 어렵고 불필요한 비용까지 발생할 수 있습니다.



필요한 것은 신뢰 대신 암호학적 증명(cryptographic proof)에 기반해, 거래 의사가 있는 두 당사자가 신뢰받는 제3자를 필요로 하지 않고 서로 직접 거래하게 해주는 전자 화폐 시스템이다. 전산적으로 철회가 불가능한 거래는 사기로부터 판매자를 보호하고, 통상적인 제3자 예치(escrow) 방법은 구매자를 보호하기 위해 쉽게 구현될 수 있다. 이 논문에서, 우리는 시간순으로 거래의 전산적 증거를 생성하는 개인 대 개인간 분산 타임스탬프 서버를 사용한 이중지불 문제의 솔루션을 제안한다. 이 시스템은 정직한 노드가 공격을 하려고 협력하는 노드 그룹보다 총체적으로 더 많은 CPU 파워를 통제하는 한 보안상 안전하다.


이 내용은 블록체인 기반 가상화폐(이 논문에서는 비트코인)의 필요성과 안정성 부분을 얘기하고 있습니다. 몇가지 용어에 대한 설명이 필요할 것 같아 작성합니다.  


1) 에스크로


에스크로(escrow)는 상거래 시에, 판매자와 구매자의 사이에 신뢰할 수 있는 중립적인 제삼자가 중개하여 금전 또는 물품을 거래를 하도록 하는 것, 또는 그러한 서비스를 말한다. 거래의 안전성을 확보하기 위해 이용된다.


구체적으로는 판매자·구매자·제삼자의 사이에서 다음과 같은 절차로 진행된다.


1. 구매자는 제3자에게 대금을 맡긴다.

2. 판매자는 제3자에게의 입금을 확인하고 구매자에게 상품을 발송한다.

3. 구매자는 송부된 상품을 확인하고 제3자에게 상품이 도착했음을 알린다. 당초의 거래 내용과 다른 경우는, 상품을 반송하거나 거래를 파기할 수 있다.

4. 제3자는 판매자에게 대금을 송금한다.

5. 판매자는 대금을 수령한다(거래의 종료).

6. 중개하는 제3자는 일정한 수수료를 받는 것으로 수익을 얻는다.



2) P2P(Peer to Peer) 분산 네트워크 기반 타임스탬프 서버


P2P 네트워크는 중앙서버 없이 Peer들 끼리 서로 서로 데이터를 전송하는 네트워크입니다. 


타임스탬프 (Timestamp)란 전자문서의 생성시점확인(존재증명) 및 진본성 확인(내용증명)을 위한 공개키 기반(PKI : Public Key Infra Structure)의 국제표준 기술이며, 전자문서가 어느 특정 시각에 존재하고 있었다는 것을 증명하는 것과 동시에, 그 시각 이후에 데이터가 변경되지 않았음을 증명하는 전자적 기술입니다.(출처 : 타임스탬프솔루션)


따라서 이 2가지를 결합한 것이 바로 P2P 분산 네트워크 서버라고 이해하면 될 것 같습니다. 즉 거래의 타임스탬프를 중앙서버 없이 P2P 네트워크에서 공유하여 이중 지불 문제를 해결하고자 한다는 내용으로 해석하였습니다.



3) 노드

노드는 이 네트워크에 참여하고 있는 Peer로 해석하였는데 자세하게는 설명하기 어려워 노드에 관한 설명을 가져왔습니다.


노드에는 풀노드와 라이트노드가 있습니다. 풀노드는 블록에 포함된 트랜잭션들과 블록전체의 정합성을 검증합니다. 이것을 통과한 블럭만 정당한 블록으로 인정하고, 로컬 데이타베이스를 업데이트하고 다른 노드로 전파시킵니다. 라이트노드는 전체 블록데이타를 검증하지도 않고, 모든 데이타를 저장하지도 않습니다. 필요한 트랜잭션 검증에 필요한 블럭헤드만 다른 외부 풀노드로 부터 받아와서 검증합니다. 
풀노드 중의 일부가 블록을 생성합니다. 블록을 생성하는 풀노드는 풀노드가 하는 모든 기능 더하기, 블럭자체를 생성해서 전파하는 역할까지 하는 것입니다. 
그런데 채굴풀에서 물려서 돌리는 채굴자들은 자체적인 블록검증을 하지 않기 때문에, 풀노드나 라이트노드를 돌리지 않습니다. 따라서 노드라고 부를 수 없습니다. 이 경우 채굴풀에서 돌리는 풀노드만 노드역할을 한다고 볼 수 있습니다.


출처 : http://www.chaintalk.io/archive/qna/812



2. 거래


 우리는 디지털 서명의 사슬로써 전자적 화폐(electronic coin)를 정의했다. 각 소유자는 화폐를 송금할 때 먼젓번 거래 내역 및 다음 소유자 공개키의 해시값에 전자적으로 서명을 하고 이 정보를 이 화폐의 끝에 첨가한다. 수금자(payee)는 소유권(ownership)의 사슬을 검증하기 위해 해당 서명을 검증할 수 있다.


 이 과정상 문제는 수금자가 소유자 가운데 누군가가 화폐를 이중지불하지 않았는지 검증할 수 없다는 점이다. 통상적인 솔루션은 신뢰받는 중앙통제기관(trusted central authority)이나 조폐국(mint)을 두고 모든 거래에서 이중지불 여부를 점검하는 것이다. 거래를 마칠 때마다 이 화폐는 조폐국으로 회수돼 새로운 화폐로 발행돼야 하고, 조폐국에서 직접 발행된 화폐만이 이중지불되지 않았다고 신뢰받는다. 이 솔루션의 문제는 전체 통화체계(the entire money system)의 운명이 은행처럼 모든 거래가 거쳐가야하는 조폐국 운영 회사에 달려 있다는 점이다.


기존 디지털 서명의 시슬로써 정의된 전자적 화폐(electronic coin)의 문제점을 담은 내용입니다. 각 화폐마다 위의 그림과 같이 소유권이 체인처럼 연결되어 있어 소유자의 개인키와 받는사람의 공개키로 거래를 만들어 소유권을 전달하는 방식으로 이해하였습니다.


이 과정에 문제가 이중 지불(Double Spending)문제인데 이를 방지하기 위해 화폐의 거래가 이루어지면 다시 중앙통제기관으로 회수되어 다시 발급되어 방지한다고 하는데 이러한 시스템은 중앙통제기관이 올바르게 존재해야 시스템이 유지되는 문제가 있습니다.  



우리에게는 먼젓번 소유자가 이전에 어떤 거래에도 서명하지 않았음을 수금자에게 알릴 수단이 필요하다. 이런 목적에서 우리는 가장 앞선 거래 하나를 인정하고, 이후 이중지불 시도에는 신경쓰지 않는다. 그런 (이중 지불된) 거래가 없음을 확인할 유일한 방법은 모든 거래를 인식하고 있는 것뿐이다. 조폐국 기반 모델에서, 조폐국은 모든 거래를 인식했고 최초로 받은 거래를 (승인 대상으로) 결정했다. 신뢰받는 (제3)자 없이 이 방식을 실현하려면, 거래는 공개적으로 알려져야 하고[1], 노드들이 거래를 받는 순서의 단일 이력에 합의하는 시스템이 필요하다. 수금자는 매 거래시 그게 첫 수금이라는 것에 노드 다수가 동의했음을 증명해야 한다.


 따라서 신뢰받는 제 3자(조폐국) 없이 이중 지불 문제를 해결하려면 거래는 공개적으로 알려져야 하고 노드들이 거래를 받는 순서를 단일 이력에 합의하는 시스템을 거쳐서 노드들의 동의에 의해 이력에 기록되 이중 지불 문제를 해결해야 한다고 합니다. 





3. 타임스탬프(Timestamp) 서버


우리가 제안하는 솔루션은 타임스탬프 서버로 시작한다. 타임스탬프 서버는 타임스탬프가 찍힌 항목 블록의 해시를 가져가 그 해시를 신문이나 유즈넷 게시물[2-5]처럼 널리 배포하는 식으로 작동한다. 이 타임스탬프는 그 데이터가, 명백히, 해시(과정)에 들어가기 위해 해당 시각부터 존재했음을 증명한다. 각 타임스탬프는 그 해시 안에 먼젓번 타임스탬프를 포함하고, 그에 앞선 것들을 하나씩 연장하는(reinforcing the ones) 타임스탬프가 찍힌 사슬을 생성한다.



 이전 타임스탬프는 이전 타임스탬프와 블록의 내용들의 해시값으로 이루어지고 계속해서 연장되어 나가는 체인으로 구성되어 있습니다. 또한, 이 내용을 모두에게 Broadcast해줍니다. 따라서 블록의 시간과 내용이 그 시간에 존재함을 말해줄 수 있고 그 값이 변경될 경우 다른 해시값이 나오기 때문에 그 값이 변경되지 않도록 Integrity을 제공해줄 수 있습니다.





4. 작업증명


개인 대 개인 기반으로 분산 타임스탬프 서버를 구현하기 위해 우리는 신문이나 유즈넷 게시물 대신 애덤 백의 해시캐시(Adam Back's Hashcash)와 유사한 작업증명 시스템[6]을 사용할 필요가 있다. 작업증명은 0비트(zero bits) 여러 개로 시작하는, SHA-256같은 해시된 값 스캐닝을 수반한다. 이에 필요한 평균 작업은 요구되는 0비트 수에 따라 지수적이며 단일 해시를 실행함으로써 확인될 수 있다. 타임스탬프 네트워크용으로, 우리는 블록의 해시에 필요한 0비트를 주는 값이 발견될 때까지 블록 안에 임시값을 증분(incrementing a nonce)하는 것으로 작업증명을 구현했다. 작업증명을 만족하는 데 한 번 CPU 동작(CPU effort)이 쓰였으면, 그 블록은 그 작업을 재수행하지 않고는 변경될 수 없다. 거기에 나중 블록이 연결되는 만큼, 블록을 변경하기 위한 재수행 작업은 그 뒤 모든 블록까지 포함한다.



 작업 증명 시스템이란 Nonce(본문 내용에는 '임시값'이라고 말하였다.)값을 찾아 새로운 블록을 생성하는 작업, 즉 Mining 개념이라 생각합니다. 블록안에 담을 Transaction과 Prev Hash를 넣고 Nonce를 넣고 SHA-256 해시로 해시 값을 구하였을 때 이 값이 정해진 0bit의 수로 시작해야 합니다. 이 과정에서 CPU 자원이 소모되며 이렇게 이전 블록의 Nonce값이 포함된 블록의 내용을 계속 해시화 하여 다음 블록의 Prev Hash에 포함되고 또 다시 Nonce값을 계산하기 때문에 서로 내용이 연결되는 체인형태로 구성됩니다. 때문에 만약에 이 체인을 공격하기 위해 즉, 새로운 체인으로 교체해버리기 위해서는 공격하고자 하는 블록부터 가장 마지막 블록까지의 길이보다 1개 이상 더 긴 블록 체인을 생성하여야 합니다. 따라서 공격자는 마지막 블록까지 Nonce값을 구해 체인으로 구성하여야 하므로 정직한 Chain을 생성하는데 소요된 CPU 자원만큼 CPU 자원을 투자해야 하고 결국 정직한 체인의 길이가 길수록 체인을 공격하기 어렵습니다.


 자세하게 블록이 어떠한 내용으로 구성되고 어떻게 해시화 하여 체인으로 구성되는지 쉽게 이해 하실 수 있는 참고 링크를 달아두겠습니다.

https://steemit.com/kr/@hanmomhanda/blockchain



작업증명은 다수결(majority decision making)의 대표성 문제도 해결한다. IP주소당 1표에 기반한 다수 조건이라면 누구든지 많은 IP를 할당할 수 있는 이에 의해 장악될(subverted) 수 있다. 작업증명은 기본적으로 CPU당 1표다. 다수의사는 최다 작업증명 동작이 투입된 가장 긴 사슬로 대표된다. 만일 다수 CPU 파워가 정직한 노드에 의해 통제된다면, 가장 정직한 사슬이 가장 빠르게 늘어나 다른 경쟁 사슬을 압도(outpace)할 것이다. 과거 블록을 변경하려면 공격자는 그 블록과 그 뒤를 잇는 모든 블록의 작업증명을 재수행해야 하고 그러면서 가장 정직한 노드들의 작업을 따라잡아 앞질러야 한다. 뒤에서 우리는 이어지는 블록이 추가될수록 더 느린 공격자가 따라잡을 확률이 지수적으로 감소함을 보이겠다.

시간이 지날수록 노드를 구동하는 하드웨어의 속도 증가와 변화하는 관여도(interest)를 보상하기 위해, 작업증명 난도(difficulty)는 시간당 평균 블록 수에 따른 평균 목표치를 조정해 결정된다. 그것들(블록)이 너무 빨리 생성되면 난도가 증가한다.


 이 작업증명은 이 P2P 네트워크의 가장 긴 체인을 구성하고 참여하고 있는 노드들의 CPU들의 과반수에 의해 인정받게 되면 새로운 블록으로 인정받아 이 체인 네트워크에 등록되게 됩니다. IP 주소에 기반하지 않고 CPU에 기반한 것은 IP는 공격자가 여러 IP를 보유하거나 가짜 IP를 생성하여 과반수의 표를 가져갈 수 있기 때문에 위험합니다. 또한 작업증명 난이도는 블록의 생성시간과 연관되어 노드에 참여하는 하드웨어가 많아지거나 하드웨어를 제작하는 기술이 발전하여 이전 블록 생성시간이 짧으면 평균 목표치를 조정하기 위해 난이도가 증가하여 발행 속도를 조절하고 있습니다. 실제로 비트코인에서 블록 생성(새로운 비트코인 1개 발행) 시간의 평균 목표치는 10분으로 설정되어 있다고 알고 있습니다.




5. 네트워크


네트워크를 실행하는 단계는 다음과 같다:


1) 새로운 거래가 모든 노드에 브로드캐스트된다.

2) 각 노드가 새로운 거래를 블록에 수집한다.

3) 각 노드가 그 블록에 맞는 난도의 작업증명 찾기에 나선다.

4) 노드가 작업증명을 찾은 시점에, 그는 모든 노드에게 그 블록을 브로드캐스트한다.

5) 노드는 모든 거래가 유효하며 아직 지불되지 않았다는 조건에 맞을 경우에만 그 블록을 승인한다.

6) 노드는 블록 승인을 표현하기 위해 먼젓번 해시로 승인된 블록의 해시를 사용해 사슬 안에 다음 블록을

생성한다.


노드는 항상 가장 긴 사슬을 정확한 것으로 간주하고 그걸 잇는 작업을 지속한다. 만일 두 노드가 동시에 다음 블록의 상이한 버전을 브로드캐스트하면, 어떤 노드는 그 중 하나 또는 다른 것을 먼저 받을 수 있다. 이 경우 그들이 먼저 받은 것을 작업하지만, 다른 분기(branch)도 저장해 그게 더 길어질 경우에 대비한다. 이 동점(tie)은 다음 작업증명이 발견되면서 깨지고 한쪽 분기가 더 길어지며; 다른 분기를 작업하던 노드는 그 뒤 (작업 대상을) 더 긴 것으로 전환한다.


 이 내용은 비트코인 네트워크에서 블록을 생성하고 체인을 잇는 작업에 대해 설명하는 내용입니다. 단계 부분의 내용을 간단하게 설명하면 새로운 거래들을 블록에 수집하고 Nonce값을 찾는 POW 과정을 거쳐 블록을 생성하면 모든 노드에게 Broadcast하여 과반수에 의해 유효한 블록으로 인정을 받게 되면 체인에 등록되고 Mining에 참가하는 다른 Node들은 만들어진 이 블록의 Hash값이 Prev Hash로 구성되는 새로운 블록을 찾는 POW과정을 진행하게 됩니다.


 만약 P2P 네트워크에서 네트워크 상 가까운 주변 Node들에게 먼저 전파되고 전파 받은 Node는 또 주변에 전파하기 때문에 이 과정에서 Delay가 생겨 새롭게 등록된 블록을 인지하지 못하거나 동시에 블록이 만들어져서 Branch가 생긴 경우는 이 2개가 모두 체인에 연결됩니다. 이 후에 한 Branch의 길이가 더 길어지게 되면 다른 Branch는 사라지며 이 Branch가 정직한 체인으로 결정되어 뒤의 POW는 이 체인의 마지막 블록으로 수행되도록 진행됩니다.



 새로운 거래 브로드캐스트가 반드시 모든 노드에게 도달할 필요는 없다. 브로드캐스트는 많은 노드에 도달하는만큼 곧 한 블록 안에 들어간다. 블록 브로드캐스트는 또한 누락된 메시지에 내성을 갖는다. 만일 노드가 블록을 받지 못하면 그는 다음 블록을 받을 때 누락된 것을 알아차리고 그걸 요청한다.


 따라서 새로운 거래는 많은 Node에 전파될 수록 더 빠르게 블록에 등록될 수 있습니다. 또한 블록이 중간에 누락되면 다음 블록을 받을 때 누락된 부분을 요청하도록 되어있습니다.



6. 보상


관례상 블록 안의 첫 거래는 블록을 만든 이의 몫이 될 새 화폐로 시작하는 특별한 거래다. 이는 화폐를 발행하는 중앙기관 없이, 노드가 네트워크를 지원할 인센티브를 더해 주며 초기에 발행한 화폐를 유통할 방법을 제공한다. 새 화폐 일정량을 꾸준히 추가하는 것은 금 채굴자가 유통하는 금을 추가하기 위해 자원을 소비하는 것과 유사하다. 우리의 경우 소비되는 것은 CPU 시간과 전기다.


CPU resource와 전기를 투자하여 Block을 생성하는 Node들 즉, 비트코인의 채굴자(Miner)들은 블록을 성공적으로 생성할 경우 1비트코인을 보상으로 받을 수 있습니다. 생성된 비트코인은 채굴자가 등록한 지갑의 주소로 들어가게 됩니다.



이 인센티브는 또 거래 수수료(transaction fees) 재원이 될 수 있다. 만일 거래에서 도출된 가치가 투입된 가치보다 작다면, 그 차이가 거래를 포함한 블록의 인센티브 가치에 더해질 거래 수수료다. 한 번 선결된 화폐 수가 유통되면, 이 인센티브는 모두 거래 수수료로 전환돼 인플레이션에서 완전히 자유로워질 수 있다.


비트코인을 전송하기 위해서는 거래 수수료(Transaction fee)를 지불해야 합니다. 이 지불된 fee는 블록을 생성한 노드가 가져가게 됩니다. 헷갈리는 부분이 모든 Transaction들의 fee를 전부 합하여 1BTC가 Miner의 보상으로 들어가는 건지 아니면 1BTC에 추가로 fee들이 주어지는 것인지는 더 공부를 해봐야 알것 같습니다.



또 이 부분에서 중요한 내용이 2100만개의 BTC가 다 발행되고 나면 POW가 끝나는 것이 아니라 계속해서 새로운 블록은 생성되고 체인에 등록되지만 이때는 만들어 질 때마다 



이 인센티브 노드들이 계속 정직하길 유도하는 데 도움을 줄 수 있다. 만일 탐욕스러운 공격자가 모든 정직한 노드보다 더 많은 CPU 파워를 모을 수 있다면, 그는 그걸 자신의 결제를 도로 훔쳐 사람들을 속이는 데 쓰는 것, 또는 새로운 화폐를 만들어내는 데 쓰는 것 사이에서 선택해야 한다. 그는 규칙대로 움직이는 게 더 이득임을 알게 돼 있는데, 규칙은 그에게 다른 모두의 몫을 합친 것보다, 시스템과 그가 보유한 부의 유효성을 해치는 것보다 더 많은 새 화폐를 베푼다.


 비트코인에서 51% 공격이라는 것을 짧게 설명하는 부분인데 51% 공격이란 비트코인에서 유효한 블록의 생성은 과반수의 동의를 얻으면 유효한 블록으로 인정된다고 하였습니다. 따라서 전체 모든 노드의 컴퓨팅 자원의 51%가 조작된 거래를 옹호하는 장부를 작성하게 된다면 정당한 거래를 했던 블록이 사라지게 되는 것입니다. 따라서 장부에 기록이 남지 않으므로 그 거래는 없던 거래가 되버리는 것입니다.


하지만 이 공격은 천문학적인 비용이 요구되므로 결국 얻어지는 이익보다 투자되는 비용이 더 커지기 때문에 정직하게 채굴을 하는 것이 더 이익이라고 논문에 적혀있습니다.


51% 공격의 자세한 내용은 해당 링크에 들어가셔서 보시면 이해하시는데 많은 도움이 되리라 생각됩니다.


https://steemit.com/kr/@easyblockchain/51


7. 디스크 공간 회수


화폐 안의 최종 거래가 충분한 블록에 묻히면, 그 전에 지불된 거래는 디스크 공간을 절약하기 위해 폐기될 수 있다. 블록의 해시를 깨지 않고 이걸 촉진하기 위해, 거래는 머클트리(Merkle Tree)[7][2][5]로 해시되며, 그 루트(root)만 블록의 해시 안에 포함된다. 그러면 오래된 블록은 트리의 분기를 쳐냄으로써 작아질 수 있다. 내부 해시는 저장될 필요가 없다.




1) 머클트리(Merkle Tree)란?


https://steemit.com/kr/@twinbraid/7mxgzy-01
https://steemit.com/kr/@twinbraid/5uzvbu-02
https://steemit.com/kr/@easyblockchain/merkle-trees


위의 링크는 머클트리(Merkle Tree)를 잘 설명한 내용을 보실 수 있는 링크입니다.


 머클트리(Merkle Tree)는 간단하게 설명하면 Leaf Node에서는 생성된 Transaction을 Hash화 하고 이 Hash값 2개를 1개의 Hash로 Hash화 하고 이렇게 만들어진 Hash를 2개묶어서 Hash화 하는 "역 2진트리"입니다. 이렇게 만들어진 Root를 Merkle Root라고 부르는데 이 Merkle Root는 모든 Transaction이 들어가있는 Hash값이므로 이 블록의 모든 Transaction이 변조되지 않았는지 검증할 수 있습니다. 또 특정 거래를 검증하고 싶은 경우 라이트 노드일 경우에는 전체의 거래내역을 다 검증할 필요 없이 중간 단계에 대한 단서를 요청하여 그 갈래에 대한 검색만으로 검증할 수 있게 해줍니다.



거래가 없는 블록 헤더는 약 80바이트가 된다. 블록이 10분마다 만들어진다고 가정하면, 80바이트 * 6 * 24 * 365 = 연간 4.2MB다. 2008년부터 통상적으로 판매되는 RAM 2GB짜리 컴퓨터 시스템, 그리고 현재 연간 1.2GB씩 성장을 예측하는 무어의 법칙으로 보면, 만일 블록 헤더가 메모리에 보존돼야 한다더라도 저장공간은 문제가 되지 않는다.


거래가 없는 블록 헤더라는 의미는 즉 모든 Transaction에 대한 모든 정보를 가지고 있지 않고 전체 트랜잭션의 Merkle Root만 가지고 있는 Light Node에 대한 내용으로 해석하였습니다. 이 용량은 연간 4.2MB씩 증가할 것으로 예상되므로 시스템 용량이 부족하여 발생하는 문제점은 없다고 설명합니다.




8. 간소화한 결제 검증


결제 검증은 전체 네트워크 노드를 구동하지 않고도 가능하다. 사용자는 그가 최장 작업증명 사슬을 가졌다고 확신할 때까지 네트워크 노드를 조회해, 얻을 수 있는 가장 긴 사슬의 블록 헤더 사본을 유지하면서, 해당 거래를 타임스탬프가 찍힌 블록에 연결한 머클 분기를 얻기만 하면 된다. 그는 자신의 거래를 검사할 수는 없지만 그걸 사슬 내 장소에 연결함으로써, 네트워크 노드가 그걸 받아들인 것과, 이후 그게 받아들여졌음을 확인한 뒤 추가된 블록을 볼 수 있다.



일반적으로 결제를 검증하기위해 풀노드를 전부 사용하여 검증하는 것은 많은 리소스를 필요로 하기 때문에 Mining을 하지 않는 일반 사용자들은 Lightweight Node를 주로 사용합니다. 이 Lightweight Node에서 특정 거래를 검증한다고 하였을 때 이 거래는 해싱되어 머클트리의 루트 안에 담겨져 있을 것입니다. 그럼 Lightweight Node는 현재 자신이 가지고 있는 블록 헤더의 사본이 가장 긴 체인에 연결되어 있는 것인지 확인하여 해당 블록이 문제가 없는지 확인합니다. 또 그 거래 내역이 기록된 블록의 Merkle Tree의 Branch를 풀노드에 요청하여 이 거래가 맞는 것인지, 전체 네트워크에서 승인된 것인지 확인할 수 있다는 내용입니다.



이처럼, 네트워크를 제어하는 노드가 정직한 한 검증은 믿을만하지만, 만일 네트워크가 공격자에 의해 과점 된다면 더 취약해진다. 네트워크 노드가 거래를 자체 검증할 수 있긴 하지만, 간소화한 방법은 공격자가 네트워크를 계속 과점할 수 있는 한 그가 조작한 거래에 의해 기만당할 수 있다. 이를 방어하기 위한 한가지 전략은 네트워크 노드가 유효하지 않은 블록을 탐지시 그로부터 경고를 받아, 사용자의 소프트웨어가 그 온전한 블록을 내려받게 하고 경고된 거래에 그 불일치(inconsistency)를 확인하도록 하는 것이다. 수금이 빈번한 비즈니스는 아마도 여전히 더 독립적인 보안과 더 빠른 검증을 위해 그들의 자체 노드를 구동하길 원할 것이다.


 이 내용은 다시 51% 공격에 관한 내용입니다. 경고 알림 시스템은 자세하게 알지는 못하지만 아마 삭제되었다는 얘기도 본것 같습니다.




9. 가치 합치기와 나누기


화폐를 독립적으로 다루는 것은 가능하더라도, 송금에 모든 푼돈(every cent)을 별도 거래로 만드는 건 무리한 일이다. 가치를 나누고 합칠 수 있도록, 거래는 복수의 입출금을 포함한다. 일반적으로 입금은 더 큰 먼젓번 거래의 단수 입금 또는 더 작은 양을 결합한 복수 입금이며, 출금은 지불용 출금 하나와 만일 있다면 송금인(sender)에게 돌려줄 거스름돈 출금 하나, 이렇게 많아야 둘이다.


펼친 부채꼴(fan-out)처럼, 거래가 여러 거래에 의존하고 그 여러 거래가 더 많은 거래에 의존하는 것은 문제가 되지 않는다는 것에 주목해야 한다. 완전 독립된(standalone) 거래 내역 사본을 추출해야 할 필요는 전혀 없다.


푼돈을 거래로 만드는 것은 무리한 일이라는 부분은 어떤 사람에게 3BTC를 보내야 할때 1BTC씩 거래를 만들어 보내는 것이 아니라 거래 한번에 3BTC를 보낼 수 있도록 여러 입금을 한번에 담고 출금은 많아야 둘이라는 의미는 내가 3BTC를 보내야 하는 상대방의 주소와 혹시 입금된 금액이 3.5 BTC라면 0.5BTC 만큼 거슬러 받아야하기 때문에 상대방의 주소로 3BTC를 보낸다는 출금 이외에 현재 거래를 보내고 있는 내 자신의 지갑주소로 0.5 BTC를 이 거래의 출금에 추가하여야 나에게 0.5 BTC가 들어오게 됩니다


이 부분은 비트코인이 장부를 기록하는 방식과 크게 연관되어 있는 부분이라 생각합니다. 비트코인의 특징은 UTXO 검증인데 이것에 대한 내용은 아래의 링크를 읽어보시면 이해에 많은 도움이 될 것 같아 첨부합니다.


https://steemit.com/coinkorea/@goldenman/utxo


UTXO를 정리하면 UTXO란 Unspent Transaction Output의 약어입니다. UTXO란 간단하게 설명하면 특정 Address를 소유주로 하는 기록된 금액 만큼의 한장짜리 수표라고 이해하였습니다. 하나의 지갑 안에 여러개의 Address를 가질 수 있는데 각각의 Address에는 하나 이상의 UTXO가 논리적으로 연결되어 있습니다. 따라서 지갑안에 총 잔액을 계산하면 여러개의 Address마다 이 Address를 소유주로 하는 UTXO에 기록된 코인의 합이 지갑의 총 잔액입니다.


앞서 예로든 3BTC 송금에서는 현재 Sender의 지갑에 총 3.5 BTC가 있고 이 3.5 BTC는 2개의 UTXO로 이루어져 있다고 가정하고 이 2개의 UTXO는 2BTC의 UTXO와 1.5 BTC의 UTXO가 있다고 가정할 경우 거래를 진행하면 저 2개의 UTXO는 사라지게 됩니다. 

송금이 완료되면 Receiver의 지갑의 특정 Address에는 이 Address를 소유주로 하는 3 BTC의 UTXO가 연결되어 총 지갑 잔고가 3 BTC만큼 추가되고 Sebder는 0.5 BTC의 출력을 본인의 지갑의 Address로 하여 Sender의 지갑의 특정 Address에는 (0.5 - Transaction fee) BTC의 UTXO가 연결되게 됩니다. 이렇게 사실은 약간 복잡하게 하는 이유는 추적을 어느정도 피하기 위해서입니다.




10. 프라이버시


전통적인 은행 모델은 참여 당사자(the parties involved)와 신뢰받는 제3자에게 정보 접근을 제한함으로써 일정 수준 프라이버시를 달성한다. 이 방법은 모든 거래를 공개할 필요성에 따라 배제되지만, 공개키 익명성을 보존해 다른 장소에서 정보의 흐름을 끊는 걸로 여전히 프라이버시가 보장될 수 있다. 대중은 누군가가 다른 누군가에게 보내는 금액을 볼 수 있지만, 그 거래에 연결된 누군가에 대한 정보는 볼 수 없다. 이는 증권거래소에서 공개되는 정보 수준과 비슷하게, 개별 거래 시각과 규모를 나타내는 "테이프(tape)"는 공개되지만, 그 당사자가 누구인지 알지는 못하는 것이다.




전통적으로는 신뢰받는 제 3자와 거래 당사자들 이외에는 정보 접근을 제한하여 일정 수준의 프라이버시를 제공합니다. 또한 증권거래소 처럼 거래 규모와 시간은 공개하지만 거래 당사자들은 공개하지 않는 방식


비트코인 지갑도 지갑을 생성하는 과정에서 개인정보를 요구하지 않습니다. 그냥 지갑 생성 프로그램을 사용하여 Address만들고 사용하며 Address를 공개하여도 그 Address를 보고서는 누구인지 알 수 없습니다.



추가 방화벽으로, 새로운 키 쌍이 각 거래마다 공통된 소유자와 연결을 유지하도록 사용돼야 한다. 어떤 연결은 다중입력 거래시 여전히 불가피하게 그 입력이 동일 소유자의 것임을 필연적으로 드러낸다. 만일 키 소유자가 공개되면, 연결은 다른 거래도 동일 소유자에게 속하는 것임을 노출할 위험이 있다.


매번 거래시 새로운 Public Key - Private Key 쌍을 사용하더라도 여러개의 입력을 갖는 경우에는 동일 소유자임이 밝혀지는 것은 키 생성 방식이 부모 자식 관계로 이루어져 있고 이들 사이에는 연결고리가 있기 때문입니다. 이 연결고리가 밝혀지면 다른 거래에서 쓰는 새로운 주소들도 그 소유자가 동일 소유자 에 속하는 것임을 알 수 있습니다.


https://steemit.com/kr/@goldenman/hd-wallet


위의 링크는 HD Wallet을 설명한 정리글 링크입니다.






11. 계산


정직한 사슬보다 더 빨리 대체 사슬을 만들어내려는 공격자의 시나리오를 고려해 보자. 만일 이런 시도가 성공한다 하더라도, 그게 아무것도 없는 곳에서 가치를 만들어내거나 공격자가 소유한 적도 없는 돈을 얻게 만드는 식으로 이 시스템을 무단 변경되도록 허용하진 않는다. 노드는 유효하지 않은 거래를 결제로 받아들이지 않으며, 정직한 노드는 그걸 포함하는 블록을 절대 받아들이지 않는다. 공격자는 오로지 자신의 거래에서 그가 최근 지출한 돈을 거둬들이는 것 하나만을 바꿀 수 있다.


 이 챕터는 앞서 말했던 블록 위변조를 위해 공격자가 변조한 블록부터 현재 가장 마지막 블록까지 생성하여 노드에 전파하는 공격방법을 수학적으로 계산하는 내용입니다. 공격자는 시스템상 소유한 적도 없는 돈을 얻게 만드는 식의 공격은 노드에서 정상적인 거래로 받아들이지 않기 때문에 자신의 거래에서 사용된 금액을 자신의 지갑으로 거두어 들이는 것 하나만 바꿀 수 있다고 합니다.



정직한 사슬과 공격자 사슬간의 경주는 이항임의보행(Binomial Random Walk)으로 특징지을 수 있다. 성공 이벤트는 정직한 사슬이 그 우위(lead)를 +1만큼 늘리는 블록 하나를 연장한 것이고, 실패 이벤트는 공격자 사슬이 그 격차를 -1만큼 좁히는 블록 하나를 연장한 것이다.


이항 임의 보행이란 정해진 2개의 방향으로 랜덤하게 이동할 때 동전 던지기처럼 시행이 많아지면 결국 제자리에 머문다는 확률 이론이다. 여기서는 사슬의 우위가 +1이면 성공, -1이면 실패로 계산하였다. 



공격자가 주어진 열세를 따라잡을 확률은 도박꾼의 파산(Gambler's Ruin) 문제와 유사하다. 도박꾼이 무제한의 신용을 갖고 열세로 시작하고 손익분기(breakeven)에 도달하려는 시도를 잠재적으로 무한한 횟수에 걸쳐 시행한다고 가정해 보자. 우리는 그가 점차 손익분기에 도달할 확률, 다시말해 공격자가 정직한 사슬을 따라잡을 확률을 다음과 같이 계산할 수 있다 [8]:




p > q 라 가정하면, 공격자가 따라잡아야 하는 블록 수가 늘어날수록 그럴 수 있는 확률은 지수적으로 감소한다. 그에게 주어진 조건상, 만일 그가 초기에 운좋게 앞으로 치고나가지 못한다면, 그의 기회는 그가 뒤쳐질수록 보이지 않을만큼 작아진다.


도박꾼의 파산문제는 도박사가 계속 도박을 할 수록 파산할 가능성이 높아진다는 확률 이론입니다. 이 식에서 p가 q보다 작을 경우에는 다음 블록의 수 z와 상관없이 따라잡을 확률이 1로 항상 따라잡을 수 있다는 결론이 나옵니다. 하지만 이 경우는 모든 노드들의 컴퓨팅 자원의 51%를 가지고 POW를 해야하기 때문에 사실상 불가능 합니다.


따라서 q가 p보다 작은 상황을 보면 이 상황에서는 z가 클 수록 확률이 지수적으로 줄어들게 됩니다. 즉, 뒤의 블록이 길수록 더욱 공격자의 성공 확률이 줄어드는 것입니다. 



이제 송금인이 새로운 거래를 변경할 수 없다고 충분히 확신하기 전까지 수취인(recipient)이 얼마나 오래 기다려야할지 고려해 보자. 송금인이 자신이 지불했음을 수취인으로하여금 한동안 믿게 한 다음, 시간이 좀 지나서 지불금을 회수하도록 만들려는 공격자라고 가정한다. 해당 수신자(receiver)는 그런 일이 생길 때 경고를 받겠지만, 송금인은 그게 늦기를 바란다.


Sender가 송금한 다음 그 금액을 회수하려고 하는 공격자로 가정할 때 Receiver는 해당 Transaction이 변경할 수 없을 정도로 시간이 흘러서 확증을 하게 될 때까지 걸리는 시간을 계산하는 내용입니다. 공격자 Sender가 되돌리려는 시도를 할 때 Receiver에게 경고 메시지가 가지만 공격자는 그 메시지가 최대한 느리게 가길 바랄 것입니다.



 수신자는 새로운 키 쌍을 생성하고 서명 직전에 송금인에게 공개키를 준다. 이는 송금인이 운좋게 충분히 앞설 때까지 계속 그 작업을 수행함으로써 미리 블록의 사슬을 준비하지 못하게 방지하고, 그 시점에 거래를 실행한다. 거래가 한 번 발신되면, 이 부정직한(dishonest) 송금인은 몰래 그의 거래를 대신할 버전으로 사슬 작업을 병행하기 시작한다. 


 수신자는 해당 거래가 블록에 추가되고 그 뒤에 z블록이 연결될 때까지 기다린다. 그는 공격자가 (블록 처리를) 진척시킨 규모를 알지 못하지만, 정직한 블록이 예상되는 블록당 시간 평균치를 따른다고 가정하면, 공격자의 잠재적 진척도는 기대값을 갖는 푸아송 분포(Poisson distribution)가 될 것이다:



이 부분은 Sender가 돈을 회수하기 위해 거래가 승인되기 이전에 미리 돌려 받는 Transaction을 만들어서 가짜 체인을 생성하지 못하도록 Receiver는 새로운 암호키 쌍으로 서명하기 직전에 Sender에게 Public Key를 전달합니다. 이렇게 함으로써 미리 만들고 있던 가짜 블록체인에 Transaction을 미리 만들어서 넣을 수 없습니다.


푸아송 분포(Poisson distribution)는 어떤 사건이 발생할 기대값과 그 사건이 일어날 횟수(k)의 확률에 대한 수식입니다. 여기서는 블록당 시간 평균치 입니다.


현재 공격자가 여전히 따라잡을 수 있는 확률을 얻기 위해, 그가 해당 시점부터 따라잡을 수 있는 확률로 만들

어낼 각 진척 규모별 푸아송 밀도를 곱한다:



분모의 무한꼬리 합산을 피하도록 정리하고...



C 코드로 바꿔서…


#include <math.h>


double AttackerSuccessProbability(double q, int z)

{

double p = 1.0 - q;

double lambda = z * (q / p);

double sum = 1.0;

int i, k;

for (k = 0; k <= z; k++)

{

double poisson = exp(-lambda);

for (i = 1; i <= k; i++)

poisson *= lambda / i;

sum -= poisson * (1 - pow(q / p, z - k));

}

return sum;

}


결과를 실행하면, z 에 따라 지수적으로 감소하는 확률을 볼 수 있다.



q=0.1

z=0 P=1.0000000

z=1 P=0.2045873

z=2 P=0.0509779

z=3 P=0.0131722

z=4 P=0.0034552

z=5 P=0.0009137

z=6 P=0.0002428

z=7 P=0.0000647

z=8 P=0.0000173

z=9 P=0.0000046

z=10 P=0.0000012


q=0.3

z=0 P=1.0000000

z=5 P=0.1773523

z=10 P=0.0416605

z=15 P=0.0101008

z=20 P=0.0024804

z=25 P=0.0006132

z=30 P=0.0001522

z=35 P=0.0000379

z=40 P=0.0000095

z=45 P=0.0000024

z=50 P=0.0000006


0.1% 미만의 P 를 풀면…


P < 0.001

q=0.10 z=5

q=0.15 z=8

q=0.20 z=11

q=0.25 z=15

q=0.30 z=24

q=0.35 z=41

q=0.40 z=89

q=0.45 z=340


음... 정확한 수학적 해석은 좀 더 시간을 두고 봐야하겠지만 결국 거래 이후의 블록의 수인 z가 늘어날 수록 공격자가 성공할 확률은 기하급수적으로 줄어들게 됩니다.



12. 결론


우리는 신뢰에 의존하지 않는 전자거래용 시스템을 제안했다. 강력한 소유권 통제를 제공하는 디지털 서명으로 만든 화폐(coins made from digital signatures)의 유력한 프레임워크로 시작했지만, 이는 이중지불 방지수단 없이는 불완전하다. 이를 해결하기 위해, 우리는 정직한 노드가 CPU 파워 대부분을 제어한다면 공격자가 전산적으로 변경하기가 금세 비현실적이 되는 작업증명을 사용해 공개된 거래 이력을 기록하는 개인 대 개인 네트워크를

제안했다. 이 네트워크의 견고함은 그 정형화 하지 않은 단순성(unstructured simplicity)에 있다. 노드는 거의 조정(coordination)없이 한 번에 모두 동작한다. 이들은 메시지가 경로를 지정받아 어떤 특정 위치로 가는 게 아니라 단지 최선의 노력을 다해 전달되면 그만이기 때문에 식별될 필요가 없다. 노드는 의지에 따라, 네트워크를 떠났다가 그가 없는 동안 벌어진 일의 증거로 작업증명 사슬을 받아들여 재합류할 수 있다. 이들은 CPU 파워를 사

용한 투표로, 유효한 블록을 연장하는 작업을 통해 그걸 승인했음을 나타내고 유효하지 않은 블록에 대한 작업을 거부함으로써 그걸 기각한다. 어떤 필요 규칙과 유인이든 이 합의 작용(consensus mechanism)을 통해 집행될 수 있다.


이 부분은 한번 읽어보시면 대부분 이해가 되는 내용이라 생각합니다. 


정형화 하지 않은 단순성때문에 네트워크의 견고함이 있다는 부분은 정형화 하지 않아도 될정도의 단순한 구조여서 오히려 더 믿을 수 있다는 정도로 해석하였습니다. 


최선의 노력을 다해 전달되면 그만이라는 부분은 Transaction이 모든 노드에 도달할 필요 없이 가능한 많은 노드에 전달되면 된다는 내용인 것 같습니다. 


마지막에 어떤 필요 규칙과 유인이든 이 합의작용을 통해 집행될 수 있다는 부분은 비트코인의 합의 메커니즘은 어떤 규칙이나 보상이 성립되게 만드는 과정을 통해 이루어질 수 있다는 내용으로 마무리됩니다.




비트코인 백서는 이렇게 마무리 짓도록 하겠습니다.


블록체인에 처음 관심을 가지게 되어 여러 세미나에 참석하여 대부분 배운 내용이지만 직접 스스로 비트코인 White Paper를 읽은것은 처음이라 생각보다 많은 시간이 걸린것 같습니다. 읽다보니 뭔가 개념이 정리된 것 같아 보람있는 시간이 되었습니다.



Medibloc (메디블록) 인터뷰 / 의료산업 + 블록체인


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


본문 내용은 해당 강의를 들은 후 정리한 내용입니다.



해당 동영상의 인터뷰 질문 내용은 아래와 같습니다.



메디블록 소개, 해결할려고 하는 문제, 방향성을 말씀해주세요

기존 의료 시스템에 환자는 불편함을 느낀다 하더라도 의사도 불편함을 느끼나요? 굳이 환자기록을 블록체인에 올려 데이터화할 필요가 있나요? 메디블록 전반적인 아키텍쳐에 대해 설명을 해주세요 큰 기득권 병원이 데이터를 제공할 유인과 이익은 무엇이고 데이터를 쉽게 내놓을까요? 환자 익명성이 침해될 여지는 없는지 그리고 이건 방지하기 위한 기술은 무엇을 사용하시나요? 데이터를 보낼때 제 개인키와 하드웨어로 그럼 서명을 하나요? 사용자가 주로 고령층일텐데 end point 보안에 있어 사용자 친화성은 어떻게 하실건가요? 메디블록이 성공하는데 가장 큰 장애물은? 정부와 법이 장애물이라면 이에 대한 전략이 있으신가요? 메디블록이 IPFS 같은 저장 시스템을 사용하신다고 했는데 어떻게 자체 구축 하실건가요? IPFS가 원하는 상용화 단계에 갈려면 어떤것이 필요하고 어떠한 문제점을 식별하셨나요? 해시값을 블록체인에 저장한다면 메디블록이 신뢰하는 3자가 되는게 아닌가요? 의료전문가 계정은 어떤 응급상황에 일반 사용자 계정 정보를 열람하는게 가능한지요? 스마트 계약서가 접근통제를 하나요? Qtum 플랫폼에서 개발하는 특별한 이유가 있나요? 암호화된 모든 의료 데이터는 메디블록 데이터베이스에 저장이 되는건가요? Parity 버그나 스마트 계약서 발전에 대한 의견은? 메디블록 스마트 계약서에서 의도치 않은 일이 일었났을때 어떤 대응을 하실건가요? 인증 방법에 대해 자세히 말씀해주세요 Indorse 익명 인증 프로토콜에 대해 설명해주세요 Steem에서 토큰 보상 인센티브 때문에 일어나는 내부자 투표 몰아주기에 대해 어떻게 생각하시나요? 영지식 증명에 대해 더 말씀해 주세요 이런 시스템에서 돌팔이는 어떻게 하나요 돌팔이 판단은 주관적이고 이를 하기 위해서는 오라클이 필요 할 수 있는데 이에 대해서는 어떻게 생각하세요? 다양한 데이터와 데이터 표준을 어떻게 플랫폼에서 포용하나요? 전세계 표준화 수치는 얼마 정도인가요? 다른 블록체인 의료 프로젝트와 메디블록의 차이점은? 다른 의료테크 시스템에 비해 메디블록이 좋은점은 뭐라고 생각하시나요? 각 나라 법과 의료 시스템이 다른데 어떻게 확장 시켜나갈 예정이신가요? 우리나라부터 도입하고 해외 확장을 하는게 맞으시죠? 사업자등록은 지브롤터에 되어 있던데 개발은 거기서 하시는 건가요? 데이터를 제공했을때 보상을 준다면 추후에는 양질 데이터 보다는 노이즈 값이 많을수도 있는데 이에 대한 생각은 어떠신지요? 데이터 재판매는 어떻게 방지하실 계획이세요? 타인 데이터를 구매하는 사람은 매우 엄격한 KYC를 거치겠네요? 나이가 많을수도 있는 소비자가 복잡한 토큰 메커니즘을 이해하고 참여할수 있을까요? 소비자층 Tezos가 ICO 이후 문제가 되고 있는데 ICO를 하면서 어떻게 신뢰를 확보하실 예정이세요? MP로 보상을 받는다면 sybil 공격은 어떻게 방지할수 있을까요? 의외로 AI쪽에서는 사용자가 생산하는 데이터를 가지고 빅데이터를 하고 싶은건데 그게 불가능 해버리지 않나요? 다른 의료기기와 메디블록 보상 시스템은 어떻게 작용을 하나요? 미국이 전세계적으로 대다수 PHR 특허를 내고 있는데 이는 어떻게 방어하실 예정인가요? 팀 소개와 자랑 해주세요 마지막으로 하고 싶으신 말씀 있으신가요?





1. 메디블록 소개, 해결할려고 하는 문제, 방향성을 말씀해주세요


최근 의료 데이터를 가공하여 제품을 생성해내는 것이 헬스케어 산업에서 중요시 되고있다. 문제는 여러 병원들에 분산된 의료 데이터를 제대로 접근하고 가용할 수 있게 만드는 작업이 문제이다. 따라서 메디블록의 목적은 이 데이터를 하나로 모아 접근을 쉽게 하고 편리하게 가용할 수 있게 하여 위의 문제를 해결하기 위함이다. 또한 환자 입장에서 여러 병원을 옮겨 다닐때마다 각 병원이 내 정보를 조각 조각씩 가지고 있는 상태여서 똑같은 검사를 진행해야 할 일이 생긴다. 그리고 그 정보는 개인정보 보호법으로 환자의 의사에 의해 제도적인 절차를 진행해야 하고 제한적으로 병원밖으로 데이터가 나갈 수 없다.


결국 메디블록은 환자들이 이러한 데이터를 밖으로 빼낼 수 있는 방법을 만들어 이 데이터를 밖으로 빼내 유용하게 사용할 수 있도록 해주는 것이다.




2. 기존 의료 시스템에 환자는 불편함을 느낀다 하더라도 의사도 불편함을 느끼나요?


불편함을 느낀다. 환자중에 특히 암같은 중증 질환의 환자는 본인의 진료 기록을 문서화하여 가지고 오는 경우가 많다. 하지만 이렇게 진료기록을 

가져오는 환자들의 경우 빠진 기록이 존재하거나 영상 기록을 가져오지 않는 경우가 많고 의사 입장에서 그 기록들을 모두 리뷰를 해야 하기 때문에 

불편함이 존재한다.




3. 굳이 환자기록을 블록체인에 올려 데이터화할 필요가 있나요?


데이터를 떼서 제대로 가져오면 문제는 없다. 하지만 과거에 앓았던 질병이나 어떤 검사를 받았는지 어떤 진단을 받았는지 모두 가져오기 어렵다.

또한 이렇게 빠진 데이터 때문에 이전 병원에 재방문하거나 재검사를 받아야 하는 불편함이 존재하기 때문에 데이터화가 필요하다.




4. 메디블록 전반적인 아키텍쳐에 대해 설명을 해주세요.


기본적으로 참여자는 3가지 분류로 나뉜다. 환자, 의료 서비스 공급자, 의료 데이터 연구자로 나뉘어 진다.


환자의 데이터 생성은 2가지 경우이다.


본인이 데이터를 생성 : 웨어러블 디바이스, 본인이 기록한 본인의 증상, 보통 이러한 데이터는 환자 본인에게는 가치있게 적용할 수 있지만 다른 연구에는 적용하기 어려움


본인이 진료를 받아 의료 전문가에 의해 데이터가 생성 : 환자에게 전달된 다음 플랫폼에 공개할 수 있을 만한 형태의 데이터로 공개된다.



가장 많이 받는 질문중 하나가 블록체인에 환자의 의료 데이터를 올리는 것은 문제가 되지 않냐는 부분인데 그런것은 아니고 의료 정보는 Off Block Chain에 저장이 되고 이 데이터의 Hash값만 블록체인에 저장해서 이 데이터가 원본과 비교하여 위변조 되지 않았다는 것을 입증하게 한다.


이 데이터를 활용하기 위해서 기존에는 큰 기업이나 대형 병원에의해 판매되어 이 들이 수익을 가져가는 구조이고 스타트업이나 중소업체에서 이러한 데이터를 구매하여 사용하기 힘들었지만 메디블록 환경에서는 본인이 필요한 데이터를 환자들에게 직접 구매하여 수익은 환자들이 가져가고 중소기업도 저렴하게 필요한 정보만 얻어 사용할 수 있다는 장점이 있다. 




5. 그렇다면 큰 기득권 병원이 데이터를 제공할 유인과 이익은 무엇이고 데이터를 쉽게 내놓을까요?


큰 병원의 경우 이러한 데이터로 이득을 취하는 병원이 있기는 하다. 하지만 데이터의 소유권은 환자에게 있고 환자가 원하면 환자에게 데이터를 제공해야 하는 의무가 있다.


별도로 최근 여러 병원에서 환자들이 자신의 의료 데이터를 볼 수 있도록 어플리케이션 형태로 제공하는 서비스나 이를 목적으로 프로젝트를 진행하고 있는 경우가 많다. 이는 병원의 마케팅과 환자에게 도움이 된다. 따라서 병원측에게도 이익이 존재한다.




6. 환자 익명성이 침해될 여지는 없는지 그리고 이건 방지하기 위한 기술은 무엇을 사용하시나요?


기본적으로 Public Block Chain에서 익명성이 보장되지 않는다는 부분은 처음부터 Account에 환자의 개인정보가 노출되어서는 안된다라는 원칙으로 디자인 되었고 Smart Contract나 Block Chain에 환자의 개인정보를 기록하는 것은 모두에게 공개하는 정보나 다름없기 때문에 절대 하지 않는다.


유일하게 Block Chain에 직접 기록하여 노출하려는 정보는 의료 기관이나 기업의 정보이다. 일반적인 Account와는 구분을 두고 있다.


의료 정보는 외부로 노출되면 민감한 정보(정신질환 등)가 많기 때문에 이러한 정보들이 노출되지 않도록 모든 정보는 기본적으로 Encryption되어 분산데이터 베이스 저장소에 저장된다.


암호화된 나의 데이터를 누군가에게 전달하기 위해서는 내 데이터를 복호화 할 수 있는 사람은 자기 자신이기 때문에 기본적으로는 내 데이터를 내 Private Key로 복호화 한 다음 전달하고자 하는 상대방의 Public Key로 Encryption한 후 전달한다.


하지만 이 방법은 resource를 많이 사용하기 때문에 문제가 되고 또 누군가 이 작업을 대신 해줄 수도 없다. 왜냐하면 내 Private Key를 누군가에게 주어야 하기 때문이다. 따라서 사용자가 직접 해야 하는데 그렇게 하지 않고 scalable 하게 만들기 위해 Nucypher라는 회사와 협약을 진행하였다.


https://www.nucypher.com/


이 회사의 기술은 Proxy re-encryption라는 기술을 보유하고 있다. 이 회사의 기술을 활용하면 환자가 본인의 데이터를 복호화 하고 암호화 하여 전달하는 것 대신 전달하고자 하는 대상에게만 제한적으로 이 데이터를 보여주는 기술이다.




7. 데이터를 보낼때 제 개인키와 하드웨어로 그럼 서명을 하나요?


Nucypher의 Proxy re-encryption을 보면 데이터를 보낼 때 내가 해야 되는 동작이 있다. 하지만 기존처럼 복호화했다가 다시 암호화 하는 것은 아니고 내 Private Key와 상대방의 Public Key를 합쳐서 일종의 Combination Key같은 것을 생성한다. 이제 Nucypher측에 내 Private Key로 암호화된 데이터와 생성된 Combination Key를 전달한다. 그러면 Nucypher의 노드에서는 내 정보도 모르고 내 Private Key도 모르는데 이 2가지를 합쳐서 데이터를 생성하면 상대방의 Private Key로만 복호화 할 수 있는 데이터로 상대방에게 전달해준다. 또한 내가 원하면 언제든지 내 정보에 대한 상대방의 권한을 revoke시킬 수 있다.


이 기술이 반드시 필요한 것은 아니지만 서비스를 훨씬 더 Scalable하게 만들기 위해서 사용한다. 사용되는 resource를 최소화 할 수 있기 때문이다.




8. 사용자가 주로 고령층일텐데 end point 보안에 있어 사용자 친화성은 어떻게 하실건가요?


이 부분에 대해서는 문제가 있다. 하지만 Private Key를 분실하거나 도난당하는 문제에 대해서는 모두가 해결해야할 문제이다. 사용법에 대한 문제는 사용하는 Application을 어떻게 개발하는지에 따라 달려있다. Application은 사용자가 Block Chain에 대해 아무것도 모르는 상태에서 사용하더라도 이 Application을 사용하였더니 내 의료정보를 한군데에 다 모아서 볼 수 있고 어딘가에서 Point가 생겨서 보상을 받을 수 있도록 만들 계획이다.




9. 장기적으로 보았을 때 메디블록이 성공하는데 가장 큰 장애물은? 정부와 법이 장애물이라면 이에 대한 전략이 있으신가요?


기존의 병원에서 이 도입을 꺼려하는 병원이 있을 것으로 생각한다. 정부 측면에서는 각 행정부처마다 입장이 다르다. 하지만 점점 산업측으로 움직이는 추세라 생각한다.


병원측에서는 큰병원보다 작은병원은 반기는 추세이지만 큰병원은 꺼릴 수 있다. 하지만 제3병원에서는 이미 의료 데이터 공유를 하기위해 여러 프로젝트가 진행중이고 성공적인 결과를 얻었으며 대형 병원에서도 정부와 연계하여 프로젝트를 진행하기를 원하고 있는 추세이다.




10. 메디블록이 Off Block Chain에 IPFS 같은 저장 시스템을 사용하신다고 했는데 어떻게 자체 구축 하실건가요?


IPFS는 오픈소스의 프로젝트이다. 따라서 대부분에 블록체인의 분산 데이터베이스 시스템에서 가장 많이 이용되는 것이 바로 IPFS 시스템이다. 메디블록에서는 이것을 그대로 가져와서 사용하는 것이 아니라 이 오픈소스의 Repository를 보면 여러 버전이나 Plugin들도 많이 존재한다. 따라서 이 IPFS위에 추가적으로 Layer를 하나 쌓아서 메디블록의 프로토콜에서만 작동하는 별도의 분산 데이터베이스 시스템을 개발할 예정이다. 처음 부분에는 이 데이터베이스 시스템을 직접 제공하려고 생각중이다. 이게 조금 더 발전해가면서 참여자들이 늘어가면 이 데이터베이스 시스템의 Rule에 충족하는 새로운 데이터베이스가 들어오면 새로운 Node로 네트워크에서 활동할 수 있도록 하는 데이터베이스 네트워크를 구축할 예정이다.



11. IPFS가 원하는 상용화 단계에 갈려면 어떤것이 필요하고 어떠한 문제점을 식별하셨나요?

IPFS를 테스트 해본 결과 이 IPFS Demon이 별거 아닌 에러에 의해서도 시스템이 다운되는 문제가 있다. 이는 데이터의 Reliability를 충족하는데 큰 문제가 된다. 따라서 이 오픈소스를 개선하고 이 위에 Layer를 쌓아서 기본적으로 2 copy이상 이 안에서 보관하려고 하고 이러한 여러가지 Concept는 File Coin에서 볼 수 있다.




12. 영상데이터는 해시값만 블록체인에 저장하고 원본데이터는 메디블록이 제공하는 Storage Service에 무료로 1GB까지 저장이 되는데 이렇게 되면 메디블록이 신뢰하는 3자가 되는게 아닌가요?


기본적으로 그러한 데이터는 사용자의 핸드폰, 컴퓨터에 저장하는 것이 먼저이고 메디블록은 사용자의 요구에 따라서 Storage Service를 제공해주는 형태이다. 이 때 사용자의 Public Key로 암호화 하여 저장되기 때문에 어떤 상황에서도 오로지 사용자만이 이 데이터를 Decryption할 수 있다. 따라서 메디블록은 신뢰하는 제 3자가 되는게 아니다.




13. 의료전문가 계정은 어떤 응급상황에 일반 사용자 계정 정보를 열람하는게 가능한지요?


응급상황에 관련한 내용으로 사용자의 기초적인 혈액형 정보같은 것은 사용자의 선택에 의해 선택적으로 정해진 rule에 의해 의료 전문가 계정들에게만 공개할 수 있다. 아무 정보를 공개하지 않아도 무방하고 제공하는 Suggestion에 따라 기초적인 데이터를 사용자가 의료 전문가 계정들이 볼 수 있게 선택적으로 공개할 수 있도록 한다.




14. 스마트 계약서가 접근통제를 하나요?



15. Qtum 플랫폼에서 개발하는 특별한 이유가 있나요?


처음에는 Qtum이 없어서 이더리움에서 개발을 하였다. 이더리움에서 EVM위에 Solidity 언어를 사용하여 Smart Contract를 작성하여 개발하였다. 하지만 Qtum 팀과 얘기해본 결과 국외사업 부분에서 금전적인 부분 뿐만 아니라 홍보나 파트너회사 소개등 지원받을 수 있는 부분이 많이 있었고 EVM에서 개발 하는 부분을 Qtum의 구조를 보면 Bitcoin UTXO기반으로 하고 있지만 중간에 인터페이스를 하나 쌓고 그 위에 EVM을 올린 상태이다. 따라서 EVM에서 개발한 내용이 모두 동작하여 Migration하는 부분에 어려움도 없어서 Qtum 플랫폼을 사용하였다.




16. 암호화된 모든 의료 데이터는 메디블록 데이터베이스에 저장이 되는건가요?


이 부분은 사용자 선택적이다. 12와 유사하다. 데이터 백업으로써 저장소를 1GB까지 저장하는 것이다. 하지만 블록체인에는 이 데이터의 Hash 값이 항상 올라가게 되어 무결성 증명을 수행할 수 있도록 한다.




17. EVM을 보았을 때 Smart Contract가 양날의 검이라고 생각한다. Parity 버그나 스마트 계약서 발전에 대한 의견은? 메디블록 스마트 계약서에서 의도치 않은 일이 일었났을때 어떤 대응을 하실건가요?


최근에 Parity 사건이 벌어진 내용을 잘 들여다 보면 EVM이나 Solidity의 문제가 아니라 단순한 개발자의 실수로 보는 측면이 많고 나도 이렇게 생각한다. 하지만 Smart Contract에 위험성이 존재한다는 측면은 항상 인지하고 대비해야 한다고 생각한다. 따라서 Smart Contract에 담는 정보는 최소한으로 담는 것을 생각해서 사용자가 데이터를 올렸을 때 얻는 Point값만 Smart Contract에 저장하려고 한다. Smart Contract가 일종의 Account처럼 사용자마다 이 Point가 있는 것이고 만약에 Smart Contract에 문제가 생겨 이 Point가 사라지는 일이 발생하더라도 이 Smart Contract에 링크되어있는 실제 데이터는 Off Block Chain에 남아있는 형태로 존재하기 때문에 이러한 문제를 미연에 방지할 수 있을 것이라 생각한다.


기술적인 측면 뿐만 아니라 이 Smart Contract로 어떤 프로그램을 만들어서 실행시키는 것은 비용이 상상을 초월한다. 따라서 이 위에서 분산컴퓨팅을 한다던가 이런것을 한다는 것은 이러한 형태라면 불가능하다. 이부분 때문에 Smart Contract를 광범위하게 사용하기는 현재 많이 어려운 것이 현실이고 이부분 때문에 많은 대안들이 연구되고 개발되고 있고 다른 방법들이 성공하게 된다면 Smart Contract는 더 활성화 될 것으로 생각한다.




18. 의료 연구자나 의료 서서비스 공급자를 인증한다고 하는데 이 하이브리드 인증 방법에 대해 자세히 말씀해주세요


하이브리드 인증 시스템은 초반에 신뢰할 만한 인증 기관, 우리나라의 경우에는 보건복지부의 시스템을 사용하고 커뮤니티에 사람이 어느정도 모여지면 이 사람들로 P2P로 인증하는 방법을 사용할 것이다. 본인이 의사임을 증명하기 위해 다른 의사 4명에게 인증을 받는 방법으로 진행할 예정이다.




19. 이 시스템에서 Indorse 익명 인증 프로토콜에 대해 설명해주세요.


Indorse는 자격증명이 아니라 Linked In에서 본인의 Skill Set(영어, C++, Java 등...)을 등록할 때 이 Skill Set에 대해 Indorse를 받아야 한다고 하면서 본인이 직접 Request를 보내게 되어있다. 하지만 이 Linked In의 이 방법은 본인이 아는 사람들에게 Indorse를 받기 쉽고 따라서 신뢰받는 정보가 아닐 수 있기 때문에 Skill Set을 등록하는 부분에 있어서 우리 병원이나 본인이 잘하는 부분에 대해 P2P로 Indorse받도록 하는데 누가 어떤 선택을 한지 모르게 Indorse 받도록 할 생각이다.




20. Steem에서 토큰 보상 인센티브 때문에 일어나는 내부자 투표 몰아주기에 대해 어떻게 생각하시나요? 영지식 증명에 대해 더 말씀해 주세요


기본적으로 우리의 시스템이 이 의료인의 기술이 어느정도까지 뛰어나다는 평가를 제공하기 위한 시스템은 아니다. 최소한에 이 사람이 이러한 Skill Set을 가지고 있다고만 알 수 있다. 또한 시스템 내에 Medipoint가 있는데 이는 내부적인 생태계에 기여한 활동이나 사람들에게 받은 평가에 대한 보상으로 이 Point를 이용해 평가할 수 있는 약간의 수치정보는 볼 수 있다.




21. 이런 시스템에서 돌팔이는 어떻게 하나요. 이러한 사람들이 처음에 어떻게든 인증을 받고 서로 Point를 몰아주어 시스템의 전반적인 신뢰도가 하락할 수 있다고 생각한다.


시스템에 인증을 해줄 때 인증을 해주는 사람은 일종의 보증금을 걸고 인증을 해주는 시스템을 적용하고 있다. 인증을 받은 사람이 누군가에게 Claim을 받아 돌팔이라는 것이 판명이 되면 인증을 해준 사람의 이 보증금을 뺏기게 되고 평판이 깎이게 된다.




22. 돌팔이 판단은 주관적이고 이를 하기 위해서는 오라클이 필요 할 수 있는데 이에 대해서는 어떻게 생각하세요? 수학적으로 증명이 되지 않는 부분에 대해 어떻게 생각하는지


Skill에 대해 수치적으로 계산할 수 있는 Method는 있지만 이 Method를 위해 수집할 수 있는 정보가 객관적으로 수집할 수 있는 부분에 대해서는 문제가 있다. 따라서 미래적으로 가져갈 수 있는 정보로 보고있다. 현재로서는 의사인지 아닌지만 판별하기 위해 인증을 한다.




23. 메디블록은 다양한 데이터와 데이터 표준들을 포용하겠다는 전략인데 어떻게 플랫폼에서 포용하나요?


의료 영상은 전세계적으로 하나의 표준으로 표준화가 되어있기 때문에 문제가 없다. 또 다른 부분에서도 몇가지 주로 쓰이는 것들이 있기 때문에 이것을 표준으로 생각해서 지원하도록 초점을 맞추고 있다. 또 다른 부분에 대해서는 지원할 수 있는 표준부터 지원해 나갈 예정이다.




24. 전세계 표준화 수치는 얼마 정도인가요?


현재 이것에 대한 통계는 부족하다. 하지만 지금 많이 쓰이는 것이 있기 때문에 이것부터 점유율이 높은 순서대로 지원할 예정이다. 정확한 통계는 없다.




25. 다른 블록체인 의료 프로젝트와 메디블록의 차이점은?


가장 큰 차이점은 2가지가 있다고 생각한다. 첫번째는 프로젝트의 토큰 매커니즘이다. 만들어내는 토큰에 대해 플랫폼안에서 무엇을 하는가 놓고 보았을 때 다른 프로젝트들은 토큰 매커니즘이 제대로 구현되어있다. 우리는 토큰 매커니즘으로 생태계를 만들려고 한다. 가장 비슷한 토큰 매커니즘이 Steem이다. 실제 이 Steem에서 인센티브가 어떻게 부여되어 사람들이 계속 활동하게 하는가를 많이 참고하였다.


두번째로 타겟층이 다르다고 생각한다. 아시아권에서는 메디블록이 거의 유일하고 미국 시장의 프로젝트들을 보면 즉, PHR 시스템을 구축하려는 팀들을 보면 우리나라와는 다르게 사람들이 주민등록번호가 없는 문제 등 난관이 너무 많다. 때문에 이 프로젝트들은 반응이 별로 좋지 못하다.




26. 다른 의료테크 시스템에 비해 메디블록이 좋은점은 뭐라고 생각하시나요?


PHR은 헬스케어 서비스와 연계하거나 병원 내부, 국가 장벽을 넘는 부분에 대해 유리하다.




27. 각 나라 법과 의료 시스템이 다른데 어떻게 확장 시켜나갈 예정이신가요? 우리나라부터 도입하고 해외 확장을 하는게 맞으시죠?


우리나라에서 어느정도 기반만 마련되면 빠르게 해외 진출을 목표로 준비하고 있다.




28. 토큰의 종류가 2가지인것 같은데 이에대한 설명, 데이터를 제공했을때 보상을 준다면 추후에는 양질 데이터 보다는 노이즈 값이 많을수도 있는데 이에 대한 생각은 어떠신지요?


기본적으로 Medi-Token이라는 일반적인 Trading이 가능한 Token이 있고 Medi-Point는 다른사람에게 Trading이 불가능한 플랫폼에서 얻을 수 있는 개인적인 포인트이다. 포인트는 플랫폼에서 본인이 권한을 행사하는 활동(데이터 수집, 생성, 판매, 공유 등)들에 대해서 이 활동들에 대한 Reward로 이 Point를 준다. 이렇게 쌓인 Medi-Point는 신뢰성을 보여주는 하나의 척도로 볼 수 있고 나중에 Medi-Token으로 바꿀 수 있는 기능을 제공하려고 한다.


만들어지는 데이터에 대헤서는 건당 Point를 인센티브로 주는 방식으로 하려고 한다. 환자가 생성하는 데이터는 가치가 떨어지고 데이터를 마구잡이식으로 생성하여 Point를 벌려고 하는 개인이 많기 때문에 데이터 양에 제한을 두는 방식을 두려고 한다.


의료 서비스 공급자가 등록하는 데이터는 환자의 승인을 받아야 등록이 가능하게 하여 방지할 예정이다.




29. 데이터 재판매는 어떻게 방지하실 계획이세요?


완전히 방지할 기술적인 대책은 없지만 블록체인에 판매 기록을 남겨 데이터 재판매가 발생한 경우 역추적하여 처벌할 예정이다.



30. 타인 데이터를 구매하는 사람은 매우 엄격한 KYC를 거치겠네요? (KYC : Know Your Customer, 고객의 신분을 확인하고 신원을 확인하는 업무 프로세스)


그렇다. KYC를 통과한 사람만 데이터를 구매할 수 있도록 할 것이다.




31. 나이가 많을수도 있는 소비자가 복잡한 토큰 메커니즘을 이해하고 참여할수 있을까요?


UI와 UX의 문제라고 생각한다. 소비자는 단순히 본인의 의료 데이터를 관리하고 사용할 수 있다는 것만 알아도 된다. 또한 젊은 사람의 경우 본인이 희귀한 질병에 걸려 많은 치료비를 감당해야 할 경우, 본인의 데이터는 매우 귀중하게 쓰여질 수 있기 때문에 사용법을 학습하여 사용할 것 같다.




32. 소비자층


아기 엄마가 주 소비자층의 하나이다. 아기 엄마는 공격적으로 데이터를 수집하기 원한다. 따라서 가장 첫번째 공략대상으로 생각한다.



33. Tezos가 ICO 이후 문제가 되고 있는데 ICO를 하면서 어떻게 신뢰를 확보하실 예정이세요? (모든 ICO들의 공통적인 문제)


투명성을 내보이기 위해 실제로 자금 사용 내역이나 계획을 공개할 예정이고 사용 이전부터 계획을 발표하고 주요한 로드맵을 큰 부분에 대해서는 미리 공개할 예정이다.




34. MP로 보상을 받는다면 sybil 공격은 어떻게 방지할수 있을까요? (시빌 공격(Sybil Attack)은 일종의 네트워크 해킹 공격으로 특정한 목적을 얻기 위해 한 명의 행위를 여러 명의 행위인 것처럼 속이는 공격 형태)


* 시빌 공격이란? http://www.bitweb.co.kr/news/view.php?idx=290


앞서 설명한 Method로는 방지가 불가능하다고 생각한다. 하지만 환자가 생성한 데이터로는 의미있는 결과를 만들어내기 힘들다고 보고 낮은 reward를 주려고 한다.




35. 의외로 AI쪽에서는 사용자가 생산하는 데이터를 가지고 빅데이터를 하고 싶은건데 그게 불가능 해버리지 않나요?


상대적으로 같은 양을 놓고 보았을 때 가치가 더 작다. 사실 환자분이 그렇게 적은 Incentive를 노리고 그렇게 진행할 거라고 생각해보지는 못했다.












'블록체인 > Medibloc' 카테고리의 다른 글

180122 Medibloc공부  (0) 2018.01.22

Medibloc (메디블록) 인터뷰 / 의료산업 + 블록체인



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


이 링크에서 해당 강의를 보실 수 있습니다.


또한 메디블록의 White Paper는 아래의 링크에서 보실 수 있습니다. 강의를 보기전에 White Paper를 읽어보시는 것을 추천합니다.


https://medibloc-homepage.oss-us-west-1.aliyuncs.com/whitepaper/medibloc_whitepaper_kr.pdf





'블록체인 > Medibloc' 카테고리의 다른 글

180123 Medibloc 내용정리  (2) 2018.01.23

<이더리움(Ethereum)의 작동원리 이해>



https://www.ddengle.com/bitcoindeveloper_voted/3392079 에서 해당 강의를 볼 수 있다.



일단 강의를 한번 보고 뒤에 정리를 하도록 하겠다.


// 정리는 마무리 하였지만 정리 과정에서 강의자료의 워터마크 때문에 유튜브 강의 영상을 캡쳐하여 정리한 내용이 있어 일단은 비공개로 발행하였다. 

문제가 되지 않으면 공개로 전환하려 한다. 


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


위 링크로 들어가면 해당 강의를 보실 수 있습니다. 


본문 내용은 위의 강의를 들으면서 저 스스로 정리한 공부 노트입니다.



4. Attack Scenarios



○ 결국 Cumulative Weight로 신뢰를 평가하기 때문에 공격자는 기존 네트워크 보다 빠른 속도로 'Cumulative Weight'를 축적하고자 함


1. 공격자가 판매자에게 물건 값을 지불하는 거래를 발행한다. 이 때 판매자는 이 거래의 Cumulative Weight가 일정 값 이상에 도달하면 물건을 공격자에게 전달한다.


2. 공격자는 Double-spending 거래를 발행한다.


3. 공격자는 자신의 Computing power를 이용하여 이중 지불된 거래를 승인하는 많은 개수의 작은 거래를 생성한다. (이 때 원래 정직한 거래는 승인하지 않는다. 두 거래 사이에 Conflict가 생기기 때문에)


4. 많은 수의 작은 거래 대신에 Weight가 매우 큰 거래를 발행하는 방법도 가능(Site 자체의 Weight가 무거움, 이것 때문에 상한 Weight를 둔다.)


5. 공격자는 이중 지불된 거래를 포함하는 Subtangle이 원거래의 Subtangle보다 빠르게 Cumulative Weight를 축적하여 원거래를 포함하는 Subtangle이 버려지기를 원함.





○ In the "ideal" situation of this mathematical model, this attack always succeeds 



// 여기선 Weight가 모두 1로 동일하다는 가정을 사용하지 않고 Weight는 3^n으로 생각한다.


// Exponential Distribution : Nonce를 찾기 시작한 시점과 Nonce를 찾은 시점의 간격이 Exponential Distribution을 따른다고 가정한다. 10시간이 될수도 있고 100시간이 될수도 있는데 일반적으로 이렇게 Parameter가 주어지면 일반적으로 이것의 역수가 된다. 비트코인으 POW도 Computing Power가 클수록 Nonce를 빨리찾는 것과 비슷한 개념이다. Tip 발생 횟수는 Poisson이고 간격이 Exponential을 따른다. 여기서는 가 컴퓨팅 파워를 의미하기 때문에 거래의 Weight를 작게 만들수록, 컴퓨팅 파워가 클수록 W는 줄어든다.


- 판매자의 원거래의 Cumulative Weight이 에 도달하면 거래를 수행하며, 이 때 도달하는 시간은 


: 정당한 노드로부터 단위시간 당 발행되는 거래 개수


: 일반적인 거래의 평균적인 weight


안에, 첫 번째 공격이 성공할 확률, => 결국 3^n0의 Weight를 가지는 Tip을 생성하는데 까지의 걸리는 시간이 t0보다 작기를 원함


----------------------------------------------------------------------------------------------------------------------------------------------------


<수학적 풀이>



가 되는데 이를 가지고 대입하면 다음과 같다.


----------------------------------------------------------------------------------------------------------------------------------------------------



- 첫 번째 공격이 실패하더라도, 원거래가 포함된 가지의 총 weight이 이중 거래의 weight인 보다 작기를 바라며 확률이 존재,


// t0 이후에 어떤 특정한 시점에서 원거래보다 큰 Weight의 거래를 만들면 된다.




○ The situation where the maximum own weight is capped at a value of 1,


// 따라서 Weight의 제한을 두지 않으면 공격의 위험이 있기 때문에 Weight를 최대 1로 가정한다. 


- 공격자는 이중 거래를 승인하는 많은 수의 nonsense 거래를 발행할 것

// 이 때에는 원거래보다 더 많은 Tip들을 붙이면 Cumulative Weight가 더 커지기 때문에 공격이 된다.


- parameter 를 가지는 exponential 변수일 때, 는 parameter 1을 가지는 exponential 변수이며 

에 대해 다음을 만족,


 

// t0까지 원거래의 Cumulative Weight (w0) 보다 이중거래의 계산속도가 더 빠르다고 가정을 한다.

 


- 이중거래가 시간 에서 원거래보다 큰 Cumulative weight 를 가질 확률은


// w0개의 Gk의 합은 w0개의 거래를 발행하는 것 까지의 걸리는 시간 (weight가 1이기 때문), m은 생각하지 않아도 된다고 설명해주신다. 각 거래를 만드는 시간 이 변수 G1, G2 ... 이 되는데 이 시간을 전부 합쳐야 한다. (Attacker가 1명이라고 가정하는 듯)


// 원거래가 더 먼저 w0까지 도달해야 하기 때문에 다음과 같이 확률을 계산한다.




- 시간 에서 이중거래가 원거래보다 큰 Cumulative weight를 가질 확률은


// 위의 식에서 t0보다 이후의 시간인 t가 되었을 때 w0보다 lambda t 만큼의 Weight가 더 증가하기 때문에 다음과 같은 식이 나온다.



:  adaptation period의 cumulative weight의 성장 속도는 보다 느리다 라는 가정을 한다. (당연한 가정)



- 즉, 이중 지불 공격이 성공할 확률은



일때 확률의 상한은 0.29 이며, 일 때, 확률의 상한은 0.00001135 이다.


- 즉, 시스템의 안전을 위해서는 이어야 하며, 차이가 크게 유지될수록 이중 지불 공격이 성공할 확률이 낮아진다. 그렇기 때문에 추가적인 안전장치를 필요로 함


- Conflict 문제 해결을 위한 알고리즘 제안: "tip selection algorithm"




○ A Parasite Chain Attack


// 기생하는 체인을 만드는 것. 붉은 색으로 찍혀있는 부분이 Double-spending이다. 발행을 하고 Cumulative weight를 쌇기 위해 Tip들을 이어서 붙임 중간의 Tip들은 main tangle을 참조하면 안된다. 참조하면 Conflict가 일어나기 때문이다. 어느정도 Weight가 쌓이면 한번에 여기있는 팁들보다 더 많은 팁들을 발행한다. 이렇게 되면 Random하게 팁을 선택할 때 이 Parasite Chain의 Tip이 선택될 확률이 증가하기 때문에 이 Parasite Chain이 Main tangle이 된다.





○ A New Tip Selection Algorithm


- Main tangle이 Attacker 보다 Cumulative weight의 증가속도가 빠르다는 사실을 이용하여 Tip selection을 위한 MCMC Algorithm 제안


1. [W, 2W] 사이의 모든 sites를 고려
// Tip Selection Algorithm을 위해서는 Full Node를 알아야 한다.


2. N개의 독립적인 particle에 대해 tip을 향해서 Independent discrete-time random walks를 수행


3. 너무 빠른 속도로 tip에 도달하는 경우 lazy tip일 가능성이 존재하므로 제외하고, tip에 도달하는 첫 2개의 tip을 승인


4. Transition Probability는 x의 Cumulative weight을 의미하며, y가 x를 승인하는 경우 transition probability는 다음과 같이 정의함




// Independent discrete-time random walks를 수행할 때 둘의 Cumulative Weight의 차이가 더 작은쪽에 더 큰 확률을 준다. 아래의 그림을 보면 13에서 시작해서 10으로도 갈 수 있고 11로도 갈 수 있지만 11이 Cumulative Weight의 차이가 더 작기 때문에 11로 진행한다. 이를 위의 식으로 정의한다. 위의 식에서 값에 의해 얼만큼 확률을 더 크게 줄 것인지 조절할 수 있다. N개의 particle에 대해 모두 이 Independent discrete-time random walks를 수행한다. 이 후 처음으로 1등으로 도달한 tip을 정당한 tip으로 간주한다. 하지만 lazy tip같은 경우 바로 갈 수 있기 때문에 너무 빨리 도착한 것은 제외한다.


// 이 알고리즘이 good tip을 잘 선택한다는 것을 보이기 위해선 lazy tip이나 bad tip들을 선택할 확률이 줄어든다는 것을 보이면 된다. 






<Independent discrete-time random walks를 수행하는 예>


<Tip Selection Algorithm을 설명하기 위한 그림>


// 위의 그림에서 lazy tips 부분을 예로 들면 Main tangle안에 있는 Transaction은 lazy과 또다른 Main tangle안의 Transaction에 의해 Approve가 되었을 것이다. 따라서 이 lazy tip이 Approve한 Main tangle안에 있는 Transaction의 Cumulative Weight는 결국 Main tangle 안에 Transaction들에 의해 결정되고 lazy tip의 Cumulative weight는 0이기 때문에 Cumulative weight의 차이가 크다. 따라서 lazy tip으로 진행할 확률은 줄어든다.

// Parasite chain의 경우에는 Attacker의 Computing Power가 전체 Main tangle의 Computing Power보다 작다고 가정하여서 Parasite Chain에서 Main tangle을 Approve한 부분을 놓고 보았을 때 Main tangle안의 Transaction에서 Parasite Chain의 Transaction의 Cumulative Weight는 결국 Attacker가 생성한 Transaction에 의해서밖에 Approve받지 못하므로 Main tangle의 Cumulative Weight와는 차이가 크다. 따라서 Parasite chain으로 진행할 확률이 줄어들게 된다.

// 하지만 IoT 환경에서 Full node를 전부 파악하고 이 Tip Selection Algorithm을 계산하는 것은 무리가 있다. 따라서 이 계산을 매번 할 수가 있을까라는 생각을 하게 된다. 이에 대한 정보는 해당 영상을 보면 light한 node는 Tip selection을 사용하지 않고 특정 node에 이 알고리즘 수행을 위임하여 Tip이 생성될 때마다 이 Tip Selection Algorithm을 매번 수행한다고 한다. 따라서 특정 node에 대한 신뢰문제가 발생한다고 한다.


○ Why the nodes would follow this algorithm.


// 많은 node들이 Reference 방식을 따른다고 하면 결국 이 Selfish node도 Reference 방식을 따르는 것이 좋다. 간단히 말해서 Tip Selection Algorithm은 결국 Tip 선택하는 것에 lazy tip쪽은 확률이 작고 good tip쪽은 확률이 크고 Parasite chain쪽은 확률이 작은 Distribution을 만드는 것이다.


- A past snapshot of the tangle

- Defines a probability distribution on the set of tips

- Generating too much competition between selfish nodes for subsequent approval

- To verify the same "bad" tips would remain small



○ Inherently different from other decentralized constructs, such as Bitcoin


// 그 분포값을 알 경우 왼쪽의 큰 Tip들이 Distribution의 값이 크다고 하면 Selfish한 노드들이 본인이 Approve될 확률을 높이기 위해 이 Tip들을 무조건적으로 선택한다면 또 다른 Selfish한 노드들이 이 Tip을 무조건적으로 또 선택하면 이 Selfish한 노드들 끼리 경쟁이 발생해서 뒤에 들어올 node들에게 Approve될 확률이 줄어들기 때문에 이 Selfish한 노드들도 결국 Random하게 Reference를 따라 Select하는 것이 낫다.




○ Splitting Attack

// Sub tangle이 2개가 되기를 바라는 것, 이 2개를 계속 유지하면서 Double-spending attack을 시도하는 공격이다.


- 2개의 branch가 동시에 자라도록 유도하여 각 branch에서 double-spending attack을 시도하는 것이 가능


- "Sharp-threshold": Too hard to maintain the balance between the two branches

// 이 경우에 막기위한 방법이 Sharp-threshold이다.


-- 예를 들어, 한 쪽 branch는 총 weight가 537이고 다른 한 쪽은 528인 경우, 각 branch를 선택할 확률이 1/2 이지만 만약 1/2보다 큰 확률로 537 weight의 branch를 선택하도록 하여 공격자가 두 branch간의 균형을 유지하지 못하도록 한다.


// 이전 식에서를 조절하면 확률을 크게주는 것이 가능하다. 이 경우 Attacker들이 균형을 맞춰주려고 한다면 굉장히 많은 Computing power를 사용해야 한다.


-- MCMC algorithm에 rapidly decaying function을 사용한다.


- Network Synchronization issue


-- 한 번에 많은 수의 거래 발행할 수 있는 노드가 존재하면 공격자가 균형을 유지하는데 어려움


-- 최근 발행된 거래의 confirmation 신뢰도가 낮으므로, branch가 더 이상 자라지 않고, 정직한 노드는 분기 이전의 거래를 confirmation하는 방법으로 방어가 가능함


- MCMC depending on both 


-- Tip의 Cumulative weight에 의해 결정함으로써 더 작은 branch로 확장 되는 것을 방지함





5. Resistance to quantum computations


○ Quantum computation에 의해서 hashing power의 향상


- Bitcoin의 경우, 기존 컴퓨터 사용시 hash값을 찾기 위해 평균적으로 개의 nonce를 체크해야 했다면 Quantum computation을 


사용하면 개만 체크하면 됨


- Hashing power 향상에 따른 난이도 조절이 요구됨



○ "Large weight" attack에 효율성 부여


- Weight의 상한선을 주기 때문에 hashing power는 에서 로 향상됨


- 거래를 발행하기 위한 전체 사용 시간 중에 hashing 과정이 차지하는 비율이 높지 않기 때문에 quantum computation으로 인한 차이가 크게 없음



























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


위 링크로 들어가면 해당 강의를 보실 수 있습니다. 


본문 내용은 위의 강의를 들으면서 저 스스로 정리한 공부 노트입니다.



3. 시스템의 안정성



○ 시스템의 안정성을 tip의 개수로 평가


- 승인되지 않은 거래가 증가하면 시스템의 불안정을 야기



○ L(t)는 시간 t에서 시스템 내에 존재하는 총 tip의 개수를 의미하며 Stable 한 상태이길 원한다.


- Positive recurrent assumption:


 

어떤 시점을 잡아도 그 때의 tip의 개수는 몇개가 될 확률이 각각 존재한다.


○ 확률적 분석을 위해 몇 가지 가정을 추가한다.


- The process of incoming transactions can be modeled by a Poisson process with the rate parameter .

 (가장 중요한 가정, 새롭게 발생되는 프로세스를 Poisson Process로 가정한다. 단위시간당 발생하는 사건의 횟수의 평균 값을 라 한다. 단위시간당 개의 거래가 평균적으로 발생한다고 가정)

- All devices has approximately the same computing power. (Weight =1로 가정한 것과 연관)

- Transaction이 't' 에 발행되면 't + h' 이후에 tangle에서 관측 가능 (평균적으로 거래 발생시간 t보다 h시간 이후에 관측이 됨)

- Tip의 개수는 roughly stationary in time(시간에 대해서 Tip의 개수는 대략 고정되어 있다)

 


- 가정의 현실성 여부 논의 가능








○  다음과 같은 가정들을 받아들일 때, 그럼 안정적인 시스템의 'Stable' 한 tip의 개수는 몇 개?


- 임의의 2개의 tip을 선택하는 경우, 




- 임의의 k개의 tip을 선택하는


---------------------------------------------------------------------------------------------------------------------------------------------------------

<수학적 풀이>



○ hidden tip

- 시간 t에서는 tip처럼 보이지만 t-h이후에 다른 새로운 tip들이 Approve 하여서 t+h 이후에는 tip이 아닌 것으로 단위시간 동안 개가 생기는데만큼의 시간이 지났으므로 으로 계산한다.


○ revealed tip

     - ,진짜 tip


따라서 시간 t에서 우리가 보는 tip의 수 


으로 계산할 수 있다.


- 이항분포


X : n번 독립시행 하였을 때 event 발생 횟수


=> 내가 원하는 이벤트가 r번 일어날 확률


이 기대값을 구하면 (n : 수행 횟수, p : 해당 이벤트가 발생할 확률)



Stable하기 위해서는 Tip을 Random하게 2번 뽑을 때 revealed tip에서 1번 고르는 쪽이 Stable 하게 할 수 있다. (Purely random 전략)따라서 


 


이 되어야 한다. 1이 되는 이유는 기존의 revealed tip 1개를 Approve 하고 자기 자신이 Tip으로 대체되야 하기 때문이다. 2면 revealed tip에서 2번 선택하기 때문에 Tip은 점점 줄어들게 된다. 따라서 



가 되고 따라서 


가 된다.


(이는 아직 Tip Selection과는 관련이 없다.)

---------------------------------------------------------------------------------------------------------------------------------------------------------


○ "purely random" 전략은 일반적으로 비효율적


- A "lazy" node: 특정 거래만 반복해서 승인하여 새로운 거래 승인에 공헌하지 않음


- A "malicious" entity: 악의적인 사용자가 많은 수의 tip을 생성하여 정직한 사용자의 tip이 상대적으로 선택될 확률 감소


- 이러한 상황을 다루기 위해 더 "좋은" tip을 선택하기 위한 알고리즘이 필요하다 : "tip selection algorithm"



○ Low load regime

- Tip의 개수가 적고, 자주 1개인 경우

- network latency가 낮고, device의 계산이 바른 경우

- 일반적으로 총 거래가 적을 경우 이지만, 거래가 적당한 규모로 증가하더라도 가능함

- Tip의 개수를 의도적으로 늘리고자 하는 공격자가 없다고 가정 <- Critical !! 따라서 일반적으로 다음의 High load regime 상황을 주로 고려한다.



○ High load regime

- Tip의 개수가 많음

- 총 거래량이 매우 많은 경우

- Computational delays together with network latency


Figure 3: Low load (top) and high load (bottom) regimes of incoming transaction flow. White squares represent verified sites, while gray squares represent tips.



3.1 Cumulative weight(= 거래의 신뢰도) 증가 속도 평가


○ In the Low load regime


- 새롭게 발행되는 모든 거래들에 의해 indirectly approved 되기 때문에 단위시간 당 의 속도로 Cumulative weight가 증가함



○ In the High load regime


- 발행된지 오래된 거래는 low load regime와 같으나, tangle에 최근 추가된 거래의 경우 adaptation period 휴에 low regime과 같은 의 속도에 도달하게 됨


- In the "adaptation period"

-- H(t) is the expected cumulative weight at time t

(시간 t에서 특정 거래의 cumulative weight 값)

-- K(t) is the expected number of tips that approved the transaction at time t

(시간 t에서 특정 거래를 승인해준 tip의 개수)


---------------------------------------------------------------------------------------------------------------------------------------------------------

<수학적 풀이>


H(t)의 도함수를 먼저 구한다.



Stable한 상태의 t 시점에서 총 Tip 개수는 개가 있다고 앞서 설명하였다.


이중 K(t - h)개의 tip들은 이전에 나를 Approve (Direct 또는 Indirect하게) 해준 Tip들이다. 새로운 Tip들이 이 Tip들이 

이 K(t - h)개의 Tip들을 선택해야 나의 Cumulative weight가 증가할 것이다.


따라서 2가지로 볼 수 있는데 Tip을 선택할 때 이 K(t-h)개를 선택하거나 아니면 다른 나머지를 선택하는 것이다.


이 상황에서는 확률의 여집합을 사용해야 한다.


개의 Tip중 Tip을 2번 선택할 때 2번 다 K(t-h)가 아닌 나머지를 선택할 확률은


이다. 이를 계산하여 정리하면 



가 된다. 따라서 아래의 함수에 새로 생기는 Tip이 나를 Approve한 Tip을 선택하는 확률값이 다음과 같이 들어가고 

개의 tip들이 새로 생겼기 때문에 아래와 같은 식을 구할 수 있다.


이고 따라서



이다.


하지만 고려하지 않은 경우가 Revealed tip과 Hidden tip을 고려하지 않았다. 이중에 반은 Revealed tip이고 반은 Hidden tip이다.


따라서 다음과 같은 상황을 고려해야 한다.



1. 나를 Approve해준 Tip이 줄어드는 상황 ( K(t)가 줄어듬 )



이 경우는 Revealed Tip만 2개 선택한 경우이다. 유효한 Tip을 2개 지우면서 Tip이 1개 생기기 때문이다. 


전체 Tip의 개수는 이고 이중에 나를 Approve해준 K(t-h)개를 선택하는데 이 K(t-h)개의 절반이 Revealed Tip이기 때문에 

 

이 경우의 확률은 다음과 같이 표현할 수 있다.




2. 팁이 1개 늘어나는 상황


이 경우는 Hidden tip만 2개 고르는 상황 또는 Hidden을 1개 선택하고 나를 Approve하지 않는 나머지 Tip들 중 1개를 선택하는 경우이다.


따라서 이 확률은 다음과 같이 표현할 수 있다.



여기서 뒤에 2를 곱해서 더 해준 것은 순서를 고려해서 무엇을 먼저 선택하는지  을 계산해준 것 때문이다.  

따라서 단위 시간동안의 팁의 개수의 Expectation은 다음과 같이 계산할 수 있다.



여기서 또 하나의 가정을 한다.



이 가정은 타당하다. 전체 Tip의 개수를 로 보았을 때 Adaptation Period이기 때문에 아직 나 자신은 Tip과 매우 가까이 있기 때문이다.


따라서 



이고 2개씩 Approve할 때 이기 때문에



가 되는데 이 식을 보면 자기 자신을 미분 하였는데 자기 자신이 다시 나왔다. 이런 함수를 Exponential Function이라 하는데 따라서


로 쓸 수 있다. 이제 적분상수 C를 찾아야 한다. 이 식을 미분하면


이고 따라서 C에 대해 전개하면


이고 


를 만족하는 함수를 LambertW-function 이라 하는데 따라서 결국 C는


가 된다. 그래서 이 식을 대입하면 다음과 같이 K(t)를 구할 수 있다.

또한  K(t-h)가 매우 작다고 가정하였기 때문에 다음과 같이 전개할 수 있다.




또 결국 미분했을때 Exponential 함수이기 때문에 H(t)는 Exponential 함수가 된다. 따라서 최종적으로


가 된다.


---------------------------------------------------------------------------------------------------------------------------------------------------------


    

-- 즉, cumulative weight는 "adaptation period"에서 기하급수적으로 증가하며 그 후에는 기울기가 인 선형함수 형태로 증가한다.




결국 Low load regime일 때는 Cumulative Weight가 Linear하게 증가한다.  High load regime일 때는 Tip에 가까운 Adaptation Period일 경우에는 Exponential 하게 증가하다가 이 Adaptation period가 끝나면 Linear하게 증가한다. (위와 같은 가정이 있을 경우) 


Adaptation Period는 비트코인의 6 confirmation 처럼 어느정도 시간이 있어야 안정화가 된다.


다음에는 몇가지 Attack Scenario를 보면서 공부를 할 예정이다.


2. 관련 용어 정의


○ 네트워크의 안정성 및 거래의 유효성을 표현하기 위한 용어 정의


- 거래의 weight는 노드가 거래를 발행하기 위하여 투자한 일의 총 량에 비례한다 :  으로 정의

-- Spam 같은 것 불가능 하도록, 엄청 짧은 시간에 특정 Weight 이상의 거래를 많이 생산하는 것은 불가능 (비트코인처럼 Hash puzzle을 풀어야 함)


- Cumulative Weight : 거래의 Weight + 이 거래를 승인한 모든 거래의 Weight의 합

- Tips : 아직 한 번도 승인되지 않은 거래

- Score : 거래의 Weight + 이 거래가 승인한 모든 거래의 Weight의 합





위 그림에서 X라는 새로운 transaction이 생겼을 때 A와 C 2개의 Tip을 Approve해주고 Tip이 됨 X의 Weight가 3이기 때문에 A와 C의 Cumulative Weight는 3씩 증가하였다.


- Height: genesis 까지 제일 긴 path

-- G has height 1 & D has height 3


- Depth: 임의의 tip까지 가장 긴 path

-- G has depth 4 & D has depth 2



○ Cumulative weight: 거래의 유효성을 나타내는 대표적인 척도


○ 각 거래의 weight가 모두 1 이라고 가정함


- Section 4의 일부분 제외





+ Recent posts