블록체인하는 만두아빠

영지식 증명(Zero-Knowledge Proof)

영지식 증명의 개념

영지식 증명은 한 사람이 다른 사람에게 어떤 문장(Statement)이 참(True)임을 증명할 때, 그 문장 자체의 참/거짓 여부를 제외하고는 어떠한 정보도 노출하지 않는 증명 방법을 말합니다. 이 때, 문장을 증명하고자 하는 사람을 증명자(Prover)라고 하고, 증명자의 문장을 검증하는 사람을 검증자(Verifier)라고 합니다. 상대방을 속일 목적을 가진 경우 해당자는 부정직하다(Dishonest)고 합니다.

영지식 증명의 개념은 Shafi Goldwasser와 Silvio Micali의 1985년 논문 "The Knowledge Complexity of Interactive Proof System"에서 처음으로 제안되었습니다. 영지식(Zero knowledge)는 Shafi Goldwasser의 한 궁금증에서 출발합니다. 암호학에서 공격자(Adversary)가 암호문 전체를 해독하지는 못했지만, 부분 부분을 해독했거나, 어떠한 내용인지는 알 수 없지만 해당 암호문의 원본 평문이 영어로 작성되었다는 사실을 알 수 있었다거나하는 등의 일부 속성을 알아냈다면 이는 암호문의 해독으로 봐야하는 것인가라는 문제입니다. Shafi Goldwasser는 암호문을 통해서 공격자가 어떠한 형태의 정보도 얻을 수 없는 Case를 영지식으로 보아야한다고 했습니다. 종합하면, 영지식 증명은 다음의 3가지 성질을 충족하는 경우가 됩니다.

영지식 증명의 3가지 성질

1. 완전성 (Completeness) : 문장이 참일 경우, 정직한 증명자는 정직한 검증자에게 이 사실을 납득시킬 수 있어야 한다.

2. 건전성 (Soundness) : 문장이 거짓인 경우, 어떠한 부정직한 증명자라도 정직한 검증자에게 이 문장이 사실이라고 납득시킬 수 없어야 한다.

3. 영지식성 (Zero-knowledgeness) : 문장이 참이면, 검증자는 문장의 참/거짓 외의 어떠한 정보도 알 수 없어야 한다.

ZKP for Kids

어려운 영지식 증명을 어떻게 하면 쉽게 설명할 수 있을까에 대한 고민의 결과로 나온 논문이 있습니다. "How to explain zero-knowledge protocols to your children"이라는 제목의 논문인데, 우리가 영지식 증명에 대해 알아볼 때 가장 많이 접하는 '알리바바의 동굴 예시'가 바로 이 논문에서 나온 것입니다.

증명자인 Peggy는 검증자인 Victor에게 알리바바 동굴 가운데의 문을 통과할 수 있는 방법을 알고 있다는 점을 증명하고 싶어합니다. 하지만 알리바바 동굴 문을 통과하는 방법에 대해서는 어떠한 정보도 알려주고 싶지는 않습니다. 이런 경우 다음과 같은 방법으로 진행하면 안전하게 Victor에게 Peggy의 지식을 증명할 수 있습니다. 영지식 증명에서 이 증명 과정을 Challenge라고 합니다.

1. 먼저 Peggy가 A, B의 두 갈림길 가운데 한 곳으로 들어갑니다. 이 때 Victor는 Peggy가 어느 방향으로 간지 알 수 없어야 합니다.

2. Peggy가 무사히 들어가고 나면, Victor는 동굴의 입구에서 Peggy에게 A/B 중 한 곳으로 나오라고 외칩니다.

3. Peggy는 Victor가 외친 방향의 통로로 나옵니다.

Peggy가 문을 통과할 수 있는 방법을 알고 있다면 문제없이 나올 수 있겠지만, 방법을 모른다면 나올 수 없을 것입니다.

만약 Peggy가 부정직한 증명자라서 Victor를 속일 목적을 가지고 있다고 하더라도 50%의 확률로 위의 Challenge를 통과할 수 있을 것입니다. 그렇다면 어떻게 하면 Peggy는 Victor에게 '확신'을 줄 수 있을까요?

간단하게, 여러번 이 과정을 반복하면 됩니다. Challenge를 단 1회 시행했을 경우 방법을 모르더라도 맞출 확률이 50%가 되지만, 계속 반복할수록 이 확률은 급격히 낮아지게 됩니다. 20번만 반복하더라도 확률은 100만분의 1로 줄어들며, 40회 반복하면 1조분의 1로 줄어듭니다. 방법을 모르는 상태에서 40번 연속으로 이 Challenge를 성공할 확률은 사실상 없다고 볼 수 있습니다. 영지식 증명에서는 이렇게 '수학적으로 증명가능'하여야 한다는 것이 중요합니다.

이 Challenge를 관찰하는 다른 제 3자의 경우에는 이 Challenge의 내용을 신뢰하기가 어렵습니다. 제 3자의 시각에서 보면, 증명자와 검증자가 사전에 미리 나올 통로의 순서를 준비했는지 아닐지 알 수 없기 때문입니다. 영지식 증명은 이와 같이 해당 증명 과정에 참여한 증명자와 검증자만이 이 사실을 확인할 수 있다는 특징이 있습니다.

알리바바의 동굴 예시는 어려운 수식과 용어, 암호학적 지식 없이도 쉽게 영지식 증명에 대한 이해를 돕는다는 측면에서 훌륭하지만 영지식 증명에 대한 공부를 알리바바의 동굴 예시로만 그쳐서는 안될 것입니다.

개념을 이해하기에는 위의 알리바바 동굴 예시의 도움으로 어렵지 않을 수 있지만, 실제 구현하는 과정에 있어서는 매우 복잡하고 까다로운 것이 영지식 증명입니다. 실제 수식으로 사용되는 ZKP의 경우 검증이 쉽도록 하기 위해 p np문제에 해당하는 모듈러 연산을 사용하는 경우가 많은데, 이 연산식이 난해할수록 보안성이 증가하기 때문에 일반적으로 아주 큰 소수(Prime number)를 사용합니다. 많은 컴퓨팅 파워를 사용하기 때문에 그동안 실제 프로토콜로 사용되는 경우가 많지 않았는데 영지식 증명을 실용적으로 할 수 있도록 고안된 zk-SNARK 프로토콜이 알려지면서 최근 개인정보보호 이슈가 대두된 블록체인 쪽에서 많이 사용되고 있습니다.

폰 노이만이 1945년 개발한 Merge Sort (합병 정렬)은 Divide and Conquer (분할 정복) 알고리즘의 하나입니다.

합병 정렬은 순서없이 뒤섞여 있는 배열(Array)을 길이가 1 이하가 될 때까지 분할하고 재귀적으로 정렬하고 다음 정렬된 부분을 병합하는 방법으로 진행합니다.

27, 10, 12, 20, 25, 13, 15, 22로 구성된 배열을 nondecreasing order(오름차순)로 정렬하는 Merge Sort는 다음과 같습니다.

각각 절반씩 Divide한 후에 길이가 1이하가 되면 정복(Conquer)을 통해 재귀적으로 정렬하고, Merge를 합니다. 최종적으로 Merge된 배열은 nondecreasing order로 정렬되어 있습니다.

위의 내용을 토대로 Input이 n, array s[1...n]이고 Output이 nondecreasing order로 정렬된 S[1...n]이 되는 Merge Sort 알고리즘을 다음과 같이 구성해볼 수 있을 것입니다.

void mergesort (int n, keytype S[]) {
	const int h = [n / 2], m = n - h;
	keytype U[1..h], V[1..m];
	
    if (n > 1) {
		copy S[1] through S[h] to U[1] through U[h];
		copy S[h+1] through S[n] to V[1] through V[m];
		mergesort(h,U);
		mergesort(m,V);
		merge(h,m,U,V,S);
	}
}

2022 OntherCon Ⅳ 참여기

11월 25일, 고려대학교 정보보호대학원 미래융합기술관 601호 강당에서 코로나 팬대믹 이후 첫 Onther의 컨퍼런스, OntherCon이 열렸습니다. 

601호 강당 앞에서 신청카드를 작성하고나면 다양한 Tokamak Network 기념품을 받아갈 수 있었습니다. Tokamak Network 뱃지와 노트, 볼펜, 그리고 (진짜 금이라고 믿으면 금이 된다고 하는) 코인.. 이라고 하나요?.. 여러 다양한 기념품과 함께 준비된 다과를 들고 입장했습니다.

저의 경우 많은 수업이 601호 강당에서 진행되는 편인데, 이렇게 꽉 차는 모습은 보기 힘들었습니다. 컨퍼런스라 그런지 외부분들도 있는 것 같고, 기자분들도 꽤 오셨습니다. 오전 10시부터 6시까지 빼곡하게 준비된 다양한 세션들이 담긴 Timetable을 확인할 수 있었습니다. 온더 직원분들 중에 절반정도는 발표하시는게 아닐까 싶을 정도로 많은 발표가 준비되어 있었습니다.

고려대학교 석좌교수님이신 임종인 교수님의 축사와 각자대표님들의 Introduction을 시작으로, 온더의 개발자분들이 각각 TOSv2와 ZKP, Optimism과 같은 L2 기술, Tokamak Swap 소개와 개선 사항에 대한 발표를 진행하였습니다.

TOSv2 발표를 맡아주신 Suah님은 실제 제가 듣고있는 대학원 수업에서도 강의를 해주고 계십니다. 온더콘 도중에 수업 일정이 있어서 함께 수업을 갔다가 같이 다시 올라와서 남은 컨퍼런스를 관전하기도 했었습니다. TOSv2는 온더의 런치패드 플랫폼인 TONStarter의 2.0 버전에 해당합니다. Bonding과 Treasury의 도입, DAO 기능 개선 등의 업그레이드가 있었고, 얼마전 런칭된 서비스다보니 관심을 특히 더 많이 받지 않았나 생각이 듭니다.

TOSv2의 Bond 마켓 경제모델 설계를 담당한 Wyatt님은 직접 발표도 진행했지만, 해외에 거주중인 팀원들의 발표에도 통역으로 세 번정도 발표무대에 섰습니다. 영어 잘하시는거 너무 부럽.. 실제 외국인 직원들도 많아서 이렇게 외국에서 Zoom을 통해 업무도하고 발표도 진행한다고 합니다. 

컨퍼런스 후반부에는 TONStarter 런치패드를 통해 런칭한 프로젝트 Lyda, 제 담당 교수님이신 이중희 교수님의 CryptoPad 소개, 이더리움 최초의 3D P2E게임인 Dragonheim의 소개가 있었습니다. 한 때 게임돌이였던 저로서는 Dragonheim이 기대가 되었습니다만, 언제 런칭될런지.. 아직 개발이 필요한 부분이 많아 보였습니다. 모델링도 그렇고..

또 마지막으로 고려대학교 블록체인 학회인 블록체인벨리와 서울대학교 기반 블록체인 학회 Deciper의 소개가 있었습니다. 블록체인벨리와 연세대 블록체인 학회 블록체인@연세 가 함께 제작한 고연전 NFT인 버미와 수리에 대한 발표가 특히 기억에 남습니다. 저도 버미 NFT를 하나 민팅받아서 가지고 있거든요. 

대학생분들이 직접 진행한 프로젝트라고 생각하기에는 너무 훌륭하고 깔끔하게 잘 진행되었던 점에서 궁금한 점이 많았었는데 발표로도 직접 보게 되어 좋았습니다. 

이후 모든 발표가 마무리되고 단체사진으로 온더콘은 종료되었습니다. 

3년만에 진행된 온더콘은 코로나 팬대믹으로 인한 사회적 거리두기가 완화된 올 하반기를 시작으로 내년부터 다시 정상진행된다고 합니다. 국내에도 다양한 컨퍼런스가 열리고, 블록체인 전문 기업들이 많이 있지만, 이번에 직접 참여한 온더콘4는 단순히 회사의 세일즈를 위한 행사의 느낌보다는 기술에 집중하고 자유롭게 토론하며 공유하는 학회에 가까운 느낌이었습니다.

아직은 기술 전반과 온더의 여러 사업 내용에 대해 모르는 것들이 많아 아쉬웠지만, 다음 온더콘에서는 열심히 공부하고 배워, 더 깊이 있는 인사이트를 얻어갈 수 있지 않을까 기대해봅니다. 자극받아 더 화이팅! 

Blockchain(블록체인) 알아보기

NFT (Non-Fungible Token)

NFT의 개념

NFT란,

JPG, GIF, 비디오 등 디지털 파일에 대한 소유권을 블록체인 상에 저장하여

위·변조가 불가능한 상태로 영구 보존하고

소유권을 탈중앙화된 형태로 누구나 확인할 수 있도록 공개해놓은

디지털 자산에 대한 일종의 블록체인 기반 전자 등기권리증

NFT를 제작, 구입한 소유자는 거래를 통해 디지털 자산을 재판매할 수 있음. 단 NFT는 인증서일뿐 원본 작품 그 자체를 의미하는 것은 아님

기존의 디지털 파일은 쉽게 무단 복제가 가능하며, 원본과 사본의 차이가 없어 소유자를 증명하기 어려웠음

NFT는 블록체인 기술을 활용하여 복제 불가능한 고유성을 가지기 때문에 희소성을 온전히 인정받을 수 있음

NFT의 장점

• P2P 거래 가능성
  • Smart Contract (스마트 계약)과 연동시켜 개인 간의 거래를 가능하게 함
• 소유권 증명과 자산 관리 용이성
  • NFT는 탈중앙화된 블록체인 상에 저장되므로 위조가 어렵고 추적이 쉬우며 소유권 분실에 대한 우려를 줄일 수 있음
• 거래, 유통 촉진
  • 토큰 자체를 1/n으로 나누어 소유권을 부분적으로 유통할 수 있게 함으로써, 디지털 자산의 거래를 촉진시킬 수 있음

NFT의 단점

• 원본 소실 위험
  • NFT 자체는 블록체인 상에 기록되어 영구히 보존되지만 실제 원본 디지털 파일은 그렇지 않음.
  • 일반 중앙집중형 서버에 보관되는 원본 파일의 경우 해킹 또는 관리 부주의로 인한 유실 우려 존재
• 희소성 문제
  • 원본 파일 자체가 디지털 파일이기에 무단 복제가 쉽고 원본과 사본의 차이가 존재하지 않음
  • 원본이라는 개념이 확실히 존재하는 회화, 조각 작품보다 희소성이 떨어질 수 있음
• 법적 분쟁 가능성
  • NFT 자체가 법적으로 유효한 소유권 이전인가에 대한 문제
  • 복제권과 전송권, 저작인격권 침해 문제
  • 재판매권(추급권, resale royalty) 인정 여부
  • NFT 자체가 현행 특금법상 가산자산에 해당하는지 여부
  • NFT 플랫폼 사업자의 책임과 면책 여부
• 환경 문제
  • NFT는 생성(민팅), 구매, 판매, 재판매 등 모든 단계에서 Transaction을 발생시키게 되어 에너지 낭비 문제가 야기됨

NFT의 다양한 응용 사례들

• 각종 디지털 수집품 : CryptoFunks, CryptoKitties, NBA TopShot 등
• 패션 : Louis Vittons, Channel, Nike 등
• 게임 아이템 : P2E 게임 (Axie Infinity ...) 등
• 티켓 발급 : WaterBomb NFT 등
• 신원 증명 및 각종 인증서 : COOV(블록체인 기반 질병정보 관리), MIT 학위증명서 등
• 부동산 : Kasa, Piece 등

NFT의 거래

NFT Marketplace

• OpenSea (https://opensea.io/)
  • 전 세계 최대 규모의 NFT 마켓플레이스
  • 판매 수수료 2.5%로 저렴한 편
• NiftyGateway (https://www.niftygateway.com/)
  • 유명 셀럽, 디지털 아티스트들의 작품만을 판매하는 고급 NFT 마켓플레이스 지향
  • 신용카드로 NFT를 구매할 수 있으며 수수료 15%로 높은  편
• NBA Topshot (https://nbatopshot.com/)
  • NBA 경기의 명장면을 담은 동영상 NFT를 구매할 수 있는 마켓플레이스
  • CryptoKitties를 개발한 DapperLaps에서 런칭
  • PoS 기반의 Flow 블록체인을 사용
  • 신용카드로 NFT 구매 가능

Nodejs 설치는 Nodejs 홈페이지에서 가능하며 LTS(Long Terms Support) 버전과 최신 버전을 확인할 수 있습니다. 일반적으로 LTS 버전을 다운로드하여 설치하는 것이 여러모로 좋습니다.

개발을 하다보면 프로젝트마다 Node 버전 호환 문제로 다른 버전을 사용해야할 때가 있습니다. 각각 다른 라이브러리나 프레임워크를 사용하게 되는 경우가 많기 때문입니다. 그때마다 Node를 지우고 필요한 버전으로 새로 설치하는 번거로움이 없이 NVM(Node Version Manager)이라는 버전 관리툴을 사용하면 쉽게 버전을 넘나들며 작업을 이어갈 수 있습니다.

Windows 환경의 경우 nvm-windows를 검색하셔서 나오는 Github 페이지에 들어가서 다운로드 가능합니다.

MacOS 환경의 경우 터미널에서 아래의 커맨드를 입력해줍니다

$ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash

제대로 설치되었는지 확인하기 위해서 터미널에서 nvm을 입력해봅니다.

원하는 버전을 설치하기 위해서는 nvm install 이후에 해당하는 버전을 작성해주면 됩니다.

$ nvm install 14.**.**

nodejs 최신 버전을 설치하거나 LTS 버전을 설치하려면 각각 node와 --lts를 입력해줍니다.

$ nvm install node

$ nvm install --lts

설치된 nodejs들의 목록을 한번에 확인하기 위해서 nvm ls를 입력합니다.

nvm ls로 목록이 나타날 때 현재 적용되어있는 버전은 옆에 *가 표시되어 있습니다.

버전 변경을 하기 위해서는 nvm use로 원하는 버전을 선택해주면 됩니다.

삭제는 간단하게 nvm uninstall 후에 삭제를 원하는 버전을 입력합니다.

npm을 통해 의존성(Dependency) 설치할 때 -D 혹은 -save--dev를 사용하여 개발에만 사용되고 실제 브라우저에서는 사용하지 않을 패키지를 별도로 관리할 수 있습니다.

개발용 의존성 설치
npm install -D
혹은
npm install -save--dev

일반 의존성 설치
npm install