PGP and the Keybase.io Security Architecture: 중앙화된 검열저항성
암호화나 네트워크 보안 분야에 조금이라도 관심이 있는 개발자분이라면, Keybase라는 서비스에 대해 한 번쯤은 들어보신 경험이 있을 것입니다. 꼭 개발자가 아니더라도, 최근 잇따르는 대기업들의 개인 정보 유출사고와 정보기관의 Mass Serveilance 이슈 등으로 인해 “유출이나 검열의 우려 없이 안전하게 사람들과 통신할 방법”을 검색하다 보면 꼭 상위권에 잡히는 서비스 중 하나가 바로 이 Keybase입니다. 아직 상당히 developer-centric한 서비스이긴 합니다만, 통신 암호화에 관심이 많은 일반 사용자들까지 충분히 쉽게 사용할 수 있도록 UX가 구성되어 있기 때문에… GnuPG의 CLI에 크게 익숙하지 않아도 공개적으로 검증 가능한 고수준 암호화를 사용할 수 있다는 것이 가장 큰 장점인 서비스이죠.
“공개적으로 검증 가능하다”라는 대목에서, 설마 그거 DApp이냐고 기대에 찬 목소리로 여쭤보시는 블록체인 종사자분들의 목소리가 여기까지 들리는 듯 하지만… 안타깝게도 Keybase는 DApp이 아닙니다. Keybase는 미국 뉴욕에 위치한 한 스타트업이 운영하는 서비스로, 연관된 모든 키 교환 서버를 이 스타트업에서 관리하고 있는 엄연히 중앙화된 서비스입니다.
중앙화되어 있는데 어떻게 “공개적으로 검증 가능한” 암호화를 구현할 수 있냐고요? 블록체인만 너무 오랫동안 파다 보면 모든 사용 케이스에서 급진적인 탈중앙화 아키텍처가 유일한 답이라고 믿게 되는 경우가 많은데, 사실 중앙화된 기존 인프라로도 공개적인 서명키 검증 정도는 충분히 가능합니다. 물론, 보다 완전한 무결성 보장을 위해 블록체인 기술의 힘을 상당히 많이 빌리고 있죠.
이번 글에서는 Keybase가 중앙화된 서비스임에도 불구하고 어떻게 공개적으로 검증 가능한 암호화 아키텍처를 구축할 수 있었는지 간단하게 알아보려 합니다. 또한, 중앙화된 서비스에서 보다 향상된 integrity/fault tolerance를 보장하기 위해 어떻게 블록체인을 활용하는지도 함께 살펴보겠습니다.
PGP 암호화 모델: 키 교환의 딜레마
이런 통신 암호화에 관한 글을 작성하거나 새로운 encrypted communication channel 솔루션 등을 설계하다 보면, 빠지지 않고 등장하는 개념이 하나 있습니다. 바로 1991년 처음 공개된 암호화 시스템인 PGP (Pretty Good Privacy)입니다.
PGP는 SSL 암호화가 처음 등장하기도 이전에 이메일을 암호화하기 위해 개발된 소프트웨어입니다. 필립 짐머만 박사에 의해 개발된 PGP는 본래 인권 운동가들을 독재정권의 탄압과 검열로부터 보호하기 위한 목적으로 사용되었으나, 30년 가까운 세월이 흐른 현재까지도 몇 차례 개량을 거쳐 가장 안전한 보안 통신 방법 중 하나로 널리 사용되고 있습니다.
매우 오래되었음에도 불구하고 PGP가 아직까지 널리 사용되고 있는 이유는, 구조적으로 타 암호화 아키텍처에 비해 비교적 단순하고 투명하면서도 안전한 암호화 방법이기 때문입니다. 본래 이메일 암호화를 위해 개발되었으므로 (루트 인증서 발급기관, 즉 CA에 의존하는 X.509 등의 모델과는 대조적으로) 하나의 서버나 통신사업자에 의존하지 않고서도 암호화 키쌍을 직접 관리할 수 있으며, 이메일 (MIME) 자체도 서로 다른 서버들끼리 통용되는 표준 프로토콜이기 때문에 메일 서버 자체에 대해서도 사용자가 완전한 통제권을 가질 수 있죠. 다시 말해, 이메일은 하나의 기업에 의해 독점되지 않고 탈중앙화되어 있는 거의 유일한 통신 방법이므로, 이메일 위에 구조적으로 당사자 말고는 아무도 복호화 키에 접근하지 않는 PGP가 결합되어 현재까지도 가장 신뢰받는 암호화 통신 방법 중 하나로 자리잡게 된 것입니다. 모순적이게도 신뢰해야 할 곳이 없기 때문에 가장 신뢰받게 될 수 있었던 것이고요. 이 점은 현재 탈중앙화된 Web3가 추구하는 점과 정확히 닮았습니다. 실제로도 PGP는 하나의 인증서 발급기관에 의존하지 않고 상대방의 공개키와 신원을 연결하는 대안적인 패러다임인 Web of trust를 처음으로 도입한 암호화 모델이기도 합니다. 탈중앙화된 웹의 선조격이죠.
As time goes on, you will accumulate keys from other people that you may want to designate as trusted introducers. Everyone else will each choose their own trusted introducers. And everyone will gradually accumulate and distribute with their key a collection of certifying signatures from other people, with the expectation that anyone receiving it will trust at least one or two of the signatures. This will cause the emergence of a decentralized fault-tolerant web of confidence for all public keys.
시간이 지날수록 (PGP를 사용할수록),사용자는 신뢰하는 송신자로 지정하고자 하는 다른 사람들의 키를 모으게 될 것입니다. 다른 모든 사람들은 각자 신뢰하는 송신자를 선택할 것입니다. 그리고 그 모든 사람들은 그 키를 수신하는 누구나 그 중 최소한 한두 개의 서명을 신뢰할 경우를 제외하고는, 점진적으로 다른 사람들에게서 얻은 신뢰 서명을 자신들의 키와 함께 모으고 주고받을 수 있게 될 것입니다. 이러한 모델은 모든 공개키에 대해 탈중앙화되고 검열저항성을 가진 신뢰 기반의 웹이 등장할 수 있도록 할 것입니다.
- Philip Zimmermann, PGP Manual 2.0, 1992
PGP는 여기에 더하여 암호화 키의 신원 그 자체를 검증하는 방법인 MSD (Mean Shortest Distance) 등의 기법을 도입해 신뢰를 더욱 더 분산화하려는 시도를 하기도 했습니다. PC와 인터넷이 본격적으로 보편화되기도 이전인 90년대 초에 이러한 발상을 했다는 것 자체가 매우 놀랍죠.
PGP의 암호화 아키텍처는 현재 등장하고 있는 최첨단 암호화 기법에 비하면 매우 단순한 편입니다. 먼저 통신 당사자별로 RSA 비대칭 키쌍을 생성한 이후, 공개키를 서로 교환합니다. 메시지를 보내고자 하는 사람은 메시지 암호화를 위한 일회용 암호화 키를 임의로 생성하고, 먼저 메시지의 본문을 이 임의생성된 키로 암호화합니다. 이후 메시지 암호화에 사용된 일회용 키를 다시 상대방의 공개키로 암호화하고, 암호화된 메시지와 암호화 키를 묶어 상대방에게 보냅니다. 수신자는 자신의 비밀키를 이용해 역순의 절차를 거쳐 원문 메시지를 알아낼 수 있습니다.
물론, 이러한 탈중앙화된 모델 대신 중앙화된 Root CA와 X.509 모델 중심으로 현대의 상용 암호화 아키텍처가 형성되게 된 것에는 이유가 있습니다. 먼저 각 개인의 정확한 신원을 공개키와 명확하고 검증 가능하게 연결지을 수 있는 매개체가 존재하지 않았습니다. WOT를 실제로 이상에서 현실로 구현하기 위해서는 상기 서술된 WOT의 키체인에 올라가는 공개키가 실제 그 개인의 것임을 증명할 수 있어야 하는데 (TTPA 모델에서는 인증서를 체인으로 묶은 Chain of trust가 3중 정도면 충분하나 WOT 모델에서는 그렇지 않음), 그것이 쉽지 않았던 것이죠. 물론 엄밀하게 말하자면 방법이 있기는 있으나, 직접 일일이 물리적으로 만나는 것을 제외하고는 키 호스팅 서버를 집이나 사무실 등에 항상 가까이 두는 방법이나 (…) WOT 패러다임을 통해 송신 도메인의 위변조 여부를 확인하는 DNSSEC와 기존 TTPA 기반 TLS 암호화 연결 등을 최소 3중 이상으로 결합하여, 신원정보를 여러 소스에서 암호화된 방법으로 수 차례 반복해 모두 동일함을 확인함으로써 개인의 신원을 명확하게 확인하는 방법 등… UX 측면에서는 절대 바람직하지 않는 방법들이 대부분입니다.
또한, 탈중앙화된 방법으로 상대방과 공개키를 처음 교환할 방법이 마땅치 않았습니다. 물론 PGP 공개키를 PGP 키 서버에 업로드하면 되지만, 이를 위해서는 특수한 별도 아키텍처를 구축해놓지 않는 한 최소한 상대방의 공개키 Fingerprint 값을 알아야 하는 경우가 대부분입니다. SKS Keyserver가 등장해 키 서버끼리 서로 공개키를 동기화할 수 있게 되기 이전에는 그 키가 “어떤 키서버에 올라가 있는지”까지도 파악해야만 했습니다. 마찬가지로, UX 측면에서 그야말로 악몽에 가깝습니다.* PGP가 30년 가까운 시간 동안 Nerd들의 전유물에서 벗어나지 못했던 이유가 바로 이것 때문입니다.
(*정확히는 상대방의 이메일 주소만 가지고도 키서버에서 키를 찾을 수는 있는데, 키의 유효성을 검증해주는 중앙화된 CA가 없기 때문에 아무나 다른 사람의 이메일 주소를 가진 키를 생성해 키서버에 올릴 수 있습니다. 따라서, 정말 이 키가 상대방의 키가 맞는지를 확인하기 위해 공개키 Fingerprint 값이 일치하는지 반드시 확인해야 합니다. 또한, 공개키를 사용해 검증된 이메일 주소가 아니어도 해당 키를 사용해 메일을 수발신할 수 있기 때문에 Fingerprint만 알고 있는 경우에도 이메일 주소까지 모두 확인해야 암호화 통신이 성립할 수 있습니다.)
이쯤 되면 Keybase가 어떤 문제를 해결하기 위해 창업한 기업인지 감이 오실 겁니다. Keybase를 사용하면 앞서 언급한 PGP의 단점들을 상당 부분 해결할 수 있습니다.
Keybase: Semi-centralized PGP Communication
Keybase의 핵심은 크게 세 가지입니다. 첫 번째는 PGP 기반의 암호화 통신이나 데이터 암호화를 매우 쉽게 사용할 수 있도록 도와주는 것이고, 두 번째는 PGP 공개키 저장과 교환을 간단하게 해 주는 것, 세 번째는 실제 개인의 SNS 프로필이나 도메인 등 개인을 식별할 수 있는 요소들과 PGP 공개키를 연결해주는 것입니다.
공식 웹사이트에서는 Keybase를 다음과 같이 소개하고 있습니다.
Keybase is a new and free security app for mobile phones and computers. For the geeks among us: it’s open source and powered by public-key cryptography.
Keybase is for anyone. Imagine a Slack for the whole world, except end-to-end encrypted across all your devices. Or a Team Dropbox where the server can’t leak your files or be hacked.
Keybase는 모바일 기기와 컴퓨터를 위한 새 무료 보안 앱입니다. Geek들을 위해 설명을 덧붙이자면, 오픈 소스일 뿐만 아니라 공개키 암호화를 사용합니다.
Keybase는 모두가 사용할 수 있습니다. 모든 기기에서 단대단 암호화된 Slack이나, 당신의 파일을 유출하거나 해킹당할 염려가 없는 팀 Dropbox를 생각하시면 됩니다.
…라고 하면 암호화된 메신저 서비스들과 별로 다를 바가 없어 보이지만, 이러한 요소들은 PGP 기반 통신과 암호화를 보다 쉽게 사용할 수 있도록 하기 위해 제공하는 부가적인 서비스들에 불과합니다. Keybase가 정말로 빛나는 부분은 중앙화의 UX상 편리성을 유지하면서도 일정 수준 이상의 fault-tolerance를 유지할 수 있다는 것, 그리고 이를 활용해 온라인 상 프로필과 PGP 공개키를 cryptographic signature로 연결함으로써 PGP를 완전히 새로운 방식으로 사용할 수 있게 되었다는 점입니다.
Keybase Cryptography Architecture
이러한 일이 어떻게 가능한지, 간단하게 Keybase의 암호화 아키텍처를 살펴보겠습니다. keybase.io에 새로 가입하게 되면 크게 두 가지를 요구하는데, 바로 개인의 기기에 Keybase 클라이언트를 설치해 계정과 연결할 것과 Keybase 계정과 연결될 새 PGP 서명키를 생성하는 것입니다.
기기에 설치되는 Keybase 클라이언트에는 PGP 서명키를 생성하고 처리할 수 있는 PGP 클라이언트가 내장되어 있습니다. 처음 Keybase를 사용한다면, 다음과 같이 자신의 이메일 주소에 연결되는 새 암호화 키를 생성하면 됩니다. 기존에 사용하던 PGP 키가 있다면 그대로 Keybase로 불러올 수도 있습니다.
이전 버전의 Keybase는 이 단계에서 생성되거나 import된 PGP 키를 검증에 직접 사용했으나, 최근에는 이 키를 직접 사용하지 않고 각 기기별로 별도의 키쌍을 발급해 Keybase 서버에 공개키를 등록하는 방식을 사용합니다. Keybase에서의 모든 서명 및 암호화 작업은 클라이언트 레벨에서 로컬로 이루어지기 때문에, Keybase 계정에서 일어난 모든 변경사항은 그 변경사항이 일어난 기기의 고유 서명키로 서명되어 Keybase 서버에 저장됩니다.
서버에 저장된다고? 그러면 내 서명과 키의 무결성을 어떻게 보증하지?
이를 위해 Keybase는 중앙화된 서비스에서 잘 볼 수 없는 개념을 차용해 사용합니다. 바로 계정의 변경사항에 대한 timestamp 기준의 스테이트 체인입니다. 이것을 Keybase에서는 Sigchain (시그체인)이라고 합니다. 예를 들어, 저의 개인 Keybase 계정을 살펴보면, 최초 계정이 생성되었을 때부터 현재까지 계정에 연결된 키를 이용해 서명한 모든 내역이 체인으로 묶여 나타납니다.
여기서 첫 번째 “제니시스 블록”에 저장된 실제 Payload 데이터를 살펴봅시다.
{
“body”: {
“device”: {
“id”: “1af42deecd8e0ba96ffa7928ba1c2718”,
“kid”: “0120523f3ddfaadfa15dfbff4c447de3d119d136dd394c77062523dd431c2e029f840a”,
“name”: “Daniel’s MacBook Pro”,
“status”: 1,
“type”: “desktop”
},
“key”: {
“host”: “keybase.io”,
“kid”: “0120523f3ddfaadfa15dfbff4c447de3d119d136dd394c77062523dd431c2e029f840a”,
“uid”: “50d1db5b9e5e72e5ba8ec047ea339319”,
“username”: “unifiedh”
},
“merkle_root”: {
“ctime”: 1555341019,
“hash”: “a9e33060ef803b81a229166ea64fedea6e06caeb9264ee2b53cf7c51b2272810f6707ab1042ca2822f60ed03763c4b05753d5ccd14d93c1d23e81562706dd8d3”,
“hash_meta”: “2308f872d7992844fa9fc3c215c6d84274a6aea045c3a1c3b44c0fd3da11ac52”,
“seqno”: 5171260
},
“type”: “eldest”,
“version”: 1
},
“client”: {
“name”: “keybase.io go client”,
“version”: “3.2.2”
},
“ctime”: 1555341041,
“expire_in”: 504576000,
“prev”: null,
“seqno”: 1,
“tag”: “signature”
}
여기서, “prev”: null과 “merkle_root”:에 주목할 필요가 있습니다. prev는 이전 Sigchain 링크 (또는 스테이트)에 대한 해시값이고, merkle_root는 모든 Sigchain 링크의 해시값을 모은 Merkle Tree의 루트 해시값입니다 (블록체인 피플이 모두 아는 그 Merkle Root 맞습니다). 여기서 이 링크 데이터는 “제니시스 링크”여서 이전에 연결된 데이터가 없기 때문에, prev 값이 null로 기록됩니다.
그렇다면, 이 체인의 무결성은 어떻게 검증할까요? 앞서 서술했듯 Keybase는 사용자의 비밀키를 직접 관리하지 않고, 기기/클라이언트별로 별도의 서명을 위한 키쌍을 생성합니다. 따라서, 본인이 이 링크를 생성했다는 것을 증명하기 위해 그 기기에만 저장되는 비밀키를 사용해 클라이언트로 해당 요청을 서명하고, 그 결과값 (key + payload)을 Signed payload 항목으로 체인에 함께 저장합니다. 서버는 해당 기기 키의 공개키를 가지고 있으므로, Signed payload를 검증해 본래 Payload 원본 데이터를 얻음을 증명할 수 있습니다.
Sigchain을 도입함으로써 얻는 장점은 또 있습니다. 기존 PGP 모델에서는 키 서버 간 완벽한 동기화가 이루어지기 힘들기 때문에, malicious한 키 서버가 임의로 키의 유효기간을 조정해 서명에 사용하는 등의 일을 막는 것이 상당히 어렵습니다. 예를 들어, 다른 키 서버에서는 이미 비밀키가 유출되어 폐기된 키를 임의로 다시 사용해 타인을 사칭할 수 있는 가능성이 있다는 뜻입니다. Sigchain을 사용하면 이러한 변경사항이 모두가 볼 수 있도록 기록되므로, 완벽하게 신원의 무결성을 보증할 수 있습니다.
그렇다면, 여러 서비스에 흩어져 있는 다양한 온라인 상 프로필을 어떻게 Keybase에서 검증할 수 있을까요? 이미 Keybase는 상술했듯 검증을 위해서 해시 체인 형태를 사용하고 있기 때문에, 해당 서비스 프로필의 등록 요청을 새로운 Sigchain 링크 데이터로 등록하고 해당 링크 데이터와 서명키가 동일하게 해당 프로필에서 확인이 가능하면 됩니다. 트위터나 DNS TXT 레코드 등과 같이 해당 데이터를 모두 넣을 수 없는 곳에서는, 링크 데이터의base64/SHA256 해시값을 올리도록 합니다. 예를 들어, Sigchain에 등록된 저의 트위터 계정 등록 요청은 다음과 같습니다.
{
“body”: {
“key”: {
“eldest_kid”: “0120523f3ddfaadfa15dfbff4c447de3d119d136dd394c77062523dd431c2e029f840a”,
“host”: “keybase.io”,
“kid”: “0120523f3ddfaadfa15dfbff4c447de3d119d136dd394c77062523dd431c2e029f840a”,
“uid”: “50d1db5b9e5e72e5ba8ec047ea339319”,
“username”: “unifiedh”
},
“merkle_root”: {
“ctime”: 1555341719,
“hash”: “798a6235ad9b09bac6edf47ea3dea53558e6d4842596485755e9dcbcb62c5cd2eecc226305ded630ef2e8a2c7787326aef5b82d1a325f0710d63b7e4cb65a703”,
“hash_meta”: “250199dcb270611f8a036b65687fadf358b23db0451cdcb4b16cc4033c69be6d”,
“seqno”: 5171390
},
“service”: {
“entropy”: “E8wwFiNeUVLOfxDSnTOZEZow”,
“name”: “twitter”,
“username”: “unifiedh”
},
“type”: “web_service_binding”,
“version”: 2
},
“client”: {
“name”: “keybase.io go client”,
“version”: “3.2.2”
},
“ctime”: 1555341726,
“expire_in”: 504576000,
“prev”: “c225b3242ffd005c7f43122aafdf60c9ba1b390aee745a8827bcc7f34558700c”,
“seqno”: 6,
“tag”: “signature”
}
그리고 제 트위터 계정에 업로드된 “검증 트윗”은 다음과 같습니다.
트윗에 나오는 이 7SzqZDhbSrucZJY_NMG8zL57CICJC4BgJuD5라는 해시값은, 앞의 Sigchain 링크 Payload의 body에 대한 SHA-256 해시값의 앞 27바이트를 취하고, 이 값에 다시 base64를 취한 값입니다. 이 트위터 계정의 주인이 이 Keybase 계정에 연결된 키들과 주인이 같다는 것을 확인하기 위해서는, 동일한 절차를 거친 해시값이 검증 트윗의 해시값과 일치한다는 것을 검증하기만 하면 됩니다. 해당 Payload는 앞선 데이터들과 해시로 연결되어 있고 클라이언트에만 저장된 기기 고유 비밀키로 서명되므로, 해당 계정에 포스팅된 Claim의 해시값 일치 여부만 확인하면 본인이 해당 검증 작업을 수행한 것이 맞다는 것을 증명할 수 있기 때문입니다.
이러한 검증 절차는 타인에 의해서도 마찬가지로 수행될 수 있습니다. 예를 들어, 제가 Keybase에서 비탈릭 부테린을 팔로우하면, 그 계정에 연결된 트위터와 레딧 계정이 그의 것이 맞다는 것을 확인하는 셈이 됩니다. 따라서, Keybase 클라이언트는 앞서 Sigchain에 등록된 프로필 데이터를 우선 JSON 형태로 반환하고, 그 데이터를 다시 저의 서명키로 서명하는 일종의 snapshot signing 절차를 거칩니다. 이렇게 되면 Keybase 서버를 믿을 수 없어도 서버에서 반환되는 JSON이 유효하다는 것을 각자 확인할 수 있으므로, 중앙화되어 있어도 여전히 trustless 모델을 따릅니다. 앞서 PGP Manual에서 언급된 Web of trust의 탈중앙화된 서명 정의를 그대로 따르면서도, 훨씬 사용하기 쉽게 만든 것입니다. 기기별로 해당 검증 절차를 반복할 필요 없이 한 번 신뢰된 사람과는 계속해서 신뢰된 상태의 통신을 유지할 수 있는 것이죠.
다 알겠는데, 그러면 Keybase 서버가 포크되어 스테이트가 달라지면 어쩌지?
Keybase의 이 “서버 포크" 문제는 비교적 최근에 와서야 해결되었습니다. 서버 포크 문제란, 쉽게 말해 Keybase의 서버가 둘로 쪼개지는 극단적인 상황에서 양측에서 저장되는 Sigchain의 스테이트가 같다는 것을 보장할 수 없다는 것입니다. 예를 들어, Keybase 서버 전체를 그대로 포크하고 DNS 레코드 조작 등을 통해 이 거짓 “포크 서버”로 사용자를 리디렉트시킬 수 있다면, 충분히 Sigchain 스테이트 조작을 통해 사용자의 신원을 조작할 수 있다는 의미입니다.* Web3 진영에서 지적하는 중앙화된 인프라의 가장 큰 문제점이기도 하죠.
(*이러한 상황을 견딜 수 있는 스토리지 아키텍처를 Byzantine Storage(비잔틴 스토리지)라고 부르는데, 해당 이론에서는 앞선 상황에서 (i) 양측의 스테이트를 하나로 합치려 시도하지 않고 (ii) 현재 데이터 스트림에서 벗어난 통신을 하지 않는다는 조건 하에서도 데이터의 무결성을 검증할 수 있는 아키텍처를 Byzantine Storage라 정의합니다. 이에 관한 학술적인 내용은 Building secure file systems out of Byzantine storage, Mazie`res, D. & Shasha, D. 논문을 참조하시면 도움이 될 듯 합니다.)
이 문제를 해결하기 위해, Keybase는 Bitcoin 블록체인의 힘을 빌리고 있습니다. Keybase Sigchain의 전체 Merkle Root를 12시간마다 주기적으로 계산하고, Keybase의 Bitcoin 주소인 1HUCBSJeHnkhzrVKVjaVmWg2QtZS1mdfaz로 서명된 트랜잭션을 만들어 그 Merkle Root를 Bitcoin 블록체인에 저장하는 것입니다. (해당 시스템은 Ethereum이 등장하기 이전 구축되었기 때문에, 아직 Ethereum 상 Smart Contract로 이전되지 않았습니다)
예를 들어, 이 글을 작성하는 현 시간 Bitcoin 블록체인에서 마지막으로 이루어진 트랜잭션은 19Qy8uL19HQJG7dAEW8DQHcD1jFs1AiD9E로 전송된 0.00000547 BTC입니다. 이 때, Keybase는 이 주소에 대한 Private Key를 가지고 있지 않으며, 따라서 트랜잭션에 담긴 만큼의 비트코인을 잃게 됩니다. 그러나, 이 주소는 그 시간에 계산된 Keybase Sigchain의 Merkle Root를 나타냅니다 (정확히는 해당 주소의 160비트 해시값). 따라서, 해당 값을 주소로부터 구해보면
이와 같으므로, Merkle Root에 대한 160비트 해시값은5c496efe5bc0df4945c07ec5ae6f8cb82c7248bb임을 알 수 있습니다. 이는 Keybase API를 통해 얻을 수 있는 Sigchain Merkle Root 서명 데이터(https://keybase.io/_/api/1.0/merkle/root.json?hash160=5c496efe5bc0df4945c07ec5ae6f8cb82c7248bb)과 hash160 값이 일치합니다.
중앙화되어도 Fault Tolerant할 수 있다
물론 이러한 Keybase의 독특한 아키텍처가 완벽하다는 것은 아닙니다. Ethereum이 본격적으로 사용되기 시작한 이후 해당 시스템이 구축되었다면, “구조적으로는” 보다 탈중앙화된 아키텍처를 제공할 수 있었을 것입니다. 하지만, Keybase와 같이 중앙화되어 있음에도 불구하고 hash-chain 구조를 일부 차용함으로써 어느 정도의 Fault Tolerance와 탈중앙화를 획득하는 서비스들의 존재는 아직 블록체인 기반의 Web 3.0 이념이 갈 길이 멀었다는 것을 오히려 반증하고 있다고 봅니다.
Web 3.0은 아직까지도 “탈중앙화”가 왜 필요한지 대중에게 제대로 납득시키지 못하고 있습니다. 하물며 중앙화된 서버를 사용하는 Keybase도 PGP 키 관리 UX를 대폭 개선했음에도 불구하고 아직까지도 Nerd들의 전유물로 남아있는데, 사용자에게 키 서명 UX를 직접 노출시키는 DApp들은 오죽할까요. (…)
결국, Web 3.0이 웹 탄생 초기 탈중앙화된 PGP와 WoT 패러다임이 중앙화된 X.509와 TTPA/CA 패러다임에 밀려 대중화에 실패한 전례를 반복하지 않기 위해서는, 기술 그 자체보다도 사용자에게 어느 정도의 번거로움을 감수할 수 있도록 하는 확실한 Use Case와 그 번거로움을 최소화할 UX 디자인이 가장 절실하다고 보여집니다. 이념만으로는 사용자에게 전혀 어필할 수 없다는 것을 지난 월드와이드웹 발전의 역사가 그대로 보여주었고, 또 UX와 컴퓨팅 환경이 상당히 많이 개선된 현재까지도 이는 개선되지 않고 있는 것만을 보아도 그렇습니다.
“중앙화되어도 이 정도까지 할 수 있는데?”라는 비평가의 질문을 뛰어넘으려면, 기존의 crypto-fanboyism에만 의존해서는 안 된다는 것을 이러한 Centralized Fault Tolerance 패러다임이 잘 보여주고 있습니다. 블록체인이 단순한 “의미 없는 분산 DB” 취급이 “쓰레기 가상코인” 취급을 받지 않으려면, 블록체인에서 출발하는 것이 아니라 실제적인 사용자 needs에서 출발하는 접근이 그 어느 때보다도 시급해 보입니다.
좀 더 넓은 곳으로 나가야 합니다. 언제까지나 hype에 갇혀 살 수는 없습니다.
