저자는 이더리움 프로젝트에 참여하고 있습니다. 저자는 BitGo, Bitrated, Codius 또는 CryptoCorp와 관계가 없습니다.
업데이트: Bitgo의 Ben Davenport가 답변했으며, 그들은 이미 CryptoCorp와 같은 순수 오라클 서비스를 지원하는 API를 보유하고 있으며 곧 브라우저 확장을 제공할 계획이라고 합니다. 그들의 신속한 대응과 건전한 보안 관행에 대한 헌신을 칭찬합니다. GreenAddress 또한 애플리케이션이 그들의 서비스에 연결할 수 있도록 API를 제공합니다.
수년간 인프라와 기술을 개선한 끝에, 다중 서명 지갑 기술이 비트코인 세계에서 마침내 진전을 이루고 있는 것 같습니다. Greenaddress.it와 BitGo는 이 분야의 주요 경쟁자로 떠올랐으며, 후자는 최근 1,200만 달러의 벤처 자금을 유치하고 1억 달러 이상의 BTC를 보관하고 있다고 자랑합니다. 다중 서명의 증가는 비트코인 생태계에서 매우 반가운 광경이며, 그 이점은 알려져 있었고 비트코인 프로토콜의 구성 요소는 거의 2년 동안 사용 가능했으며 이제는 주류 소비자들이 그 열매를 누릴 수 있게 되었습니다. 다중 서명의 특정 이점에는 소비자-상인 에스크로 애플리케이션이 포함되어, 중재자들이 비트코인 상거래를 상대적으로 안전하고 사기 없는 방식으로 만들 수 있는 개방적이고 자유로운 시장을 허용하며, 개인적인 사용 사례로는 저축 지갑이 있어 사용자가 개인 키 중 하나의 손실이나 손상을 방지할 수 있습니다.
소비자 보호가 주요 관심사로 떠오른 시점에서, BitLicense 규제가 암호화폐 비즈니스에 엄청난 수준의 제한을 부과하고 있는 가운데, 다중 서명은 소비자 보호를 위한 규제 중심 접근 방식의 대안으로서의 약속을 제공합니다. 각 개별 비즈니스가 신뢰할 수 있는지를 확실히 하려는 대신, 우리는 단일 실패 지점을 최대한 제거하고 주로 숫자의 안전성에 의존하는 시스템을 설정할 수 있습니다. 그러나 다중 서명이 잠재적으로 혁신적인 기술이긴 하지만, 일부 비즈니스가 실제로 신뢰가 없는 상태로 존재하기 위해 노력하지 않고 주소가 “3”으로 시작하는 브랜드 이점을 주장하려고 할 위험이 있습니다. 이 기사의 요점은 “좋은 다중 서명”의 개념을 정의하는 것입니다. 즉, 개인에 대한 신뢰의 필요성을 실제로 제거하고 소비자 보호를 촉진하는 기술과 “나쁜 다중 서명” 즉, 단순한 암호 경제적 보안 극장 간의 경계를 결정하려고 합니다.
클라이언트 측 혁명
실제 다중 서명에 들어가기 전에, 여러 회사에서 보안 강화를 위해 사용하고 있는 특정 기술인 클라이언트 측 웹 앱을 먼저 분석해야 합니다. 클라이언트 측 웹 앱이 자리 잡기 전에는 비트코인 클라이언트에서 두 가지 지배적인 패러다임이 있었습니다. 첫째, 데스크톱 클라이언트는 사용자가 컴퓨터에 직접 다운로드하는 프로그램입니다. 데스크톱 클라이언트의 장점은 사용자가 자신의 기기에서 개인 키를 직접 보유하므로 자금을 보관하기 위해 제3자를 신뢰할 필요가 없다는 것입니다. 그러나 이는 사용성 비용이 발생합니다: 사용자가 애플리케이션을 다운로드해야 합니다. 둘째, 서버 측 웹 지갑은 제3자가 비트코인을 보관하고 사용자가 소프트웨어를 다운로드하지 않고도 Google 또는 Facebook 계정과 유사한 계정을 사용하여 편리하게 입금하고 인출할 수 있게 해줍니다. 이는 높은 사용성을 제공하지만 신뢰가 필요하다는 단점이 있습니다.
클라이언트 측 웹 앱은 우아한 제3의 해결책입니다: 웹사이트에 접근하는 것은 여전히 웹앱을 사용하지만 소프트웨어를 다운로드할 필요가 없으며, 개인 키는 클라이언트 측에서 웹 브라우저 내에서 Javascript를 사용하여 저장되고 거래가 서명됩니다. 따라서 이 애플리케이션은 신뢰할 수 있는 서버 측 지갑이 제공하는 웹 인터페이스와 동일한 편리함을 제공하지만, 서버는 사용자의 개인 키에 접근할 수 없고 사용자가 접근할 수 있습니다. 현재 가장 인기 있는 클라이언트 측 지갑은 아마도 blockchain.info일 것입니다.
이제 이 패러다임의 장점을 평가해 보겠습니다. 클라이언트 측 Javascript는 비판이 없는 것은 아닙니다; Matasano의 “Javascript Cryptography Considered Harmful”이라는 전체 기사가 있습니다. 이 글은 클라이언트 측 브라우저 기반 암호화의 모든 이점을 부정하는 극단적인 내용이지만, 유효한 점을 제기합니다. 특히 브라우저 Javascript를 다운로드할 때 여전히 소스를 신뢰하고 있다는 점입니다. 즉, blockchain.info 또는 blockchain.info의 악의적인 직원이 원한다면, 또는 정부가 그들을 강요한다면, 그들은 단순히 사용자의 개인 키를 가져가고 모든 자금을 그들의 주소로 보내는 거래를 서명하는 브라우저 코드를 보낼 수 있으며, 사용자는 너무 늦기 전까지는 그 차이를 알지 못할 것입니다. 이 주장을 극단적으로 끌고 간다면, 다운로드 가능한 클라이언트가 개인 키를 훔치는 버전을 배포할 가능성도 있지만, 직관적으로 볼 때 이 경우에는 문제가 훨씬 덜 심각한 것 같습니다. 특히 소프트웨어를 한 번만 다운로드하기 때문입니다.
그렇다면 각 경우에서 소프트웨어 제공자를 얼마나 신뢰하고 있는 걸까요? 각 경우에서 성공적인 공격이 발생하기 위해 필요한 사항을 분해해 보겠습니다:
- 소스에서 빌드된 데스크톱 클라이언트 – 제공자 또는 제공자의 시스템에 해킹한 공격자는 백도어를 포함한 패치를 클라이언트의 Github 저장소에 제출해야 하며, 누군가 조직 내부 또는 외부에서 소스 코드를 스캔하고 이를 알아차리기 전에 클라이언트를 다운로드해야 합니다.
- 바이너리 데스크톱 클라이언트 (일반 사람들이 사용하는 옵션) – 제공자 또는 제공자의 시스템에 해킹한 공격자는 백도어를 포함한 클라이언트의 버전을 컴파일하고 게시해야 하며, 누군가 조직 내부에서 악행을 감지하기 전에 다운로드해야 합니다 (대부분의 경우 바이너리를 디컴파일하여 백도어를 감지하는 것은 너무 어렵기 때문에 내부에서 발생해야 하며, 장기적으로는 exploit이 발견되면 이를 격리할 수 있습니다).
- 클라이언트 측 브라우저 웹앱 – 공격자는 백도어를 포함한 클라이언트의 버전을 콘텐츠 전송 네트워크에 신속하게 삽입해야 하며, 그 시점과 악의적인 버전이 오프라인으로 전환되는 시점 사이에 로그인하는 모든 사용자만이 취약합니다.
- 서버 측 브라우저 웹앱 – 공격자는 사이트의 콜드 월렛에 접근해야 하며, 이 시점에서 모든 사용자의 계정이 손상됩니다.
따라서 우리는 보안의 계층 구조를 볼 수 있으며, 아래로 내려갈수록 덜 안전하고 더 많은 신뢰가 필요합니다. 한 가지 중요한 구분은 단기 공격자와 장기 공격자 간의 차이입니다: 악의적인 회사인지, 아니면 누군가가 몇 분 또는 몇 시간 동안 어떤 exploit을 통해 그들의 서버에 침입한 것인지입니다. 장기 공격자에 대해, 오픈 소스 저장소에서 이전 버전을 직접 다운로드하는 것만이 도움이 될 수 있습니다. 단기 공격자에 대해서는 바이너리 데스크톱 애플리케이션이 상당히 잘 작동하며, 클라이언트 측 브라우저 웹앱조차도 비극을 소수의 사용자로 제한할 수 있습니다.
일반적으로 데스크톱 사례와 브라우저 사례 간에는 근본적인 차이가 있습니다: 처음 두 경우에서는 공격자가 짧은 시간 동안 접근할 경우, 보안이 올바르게 설정되어 있다면 전혀 문제가 되지 않으며, 문제는 제때 수정될 수 있지만 후자의 경우에는 문제가 됩니다. 따라서 클라이언트 측 브라우저 기반 앱은 서버 기반 지갑에 비해 보안이 부분적으로만 향상됩니다.
이 문제를 어떻게 해결할 수 있을까요? 가장 간단한 접근 방식은 클라이언트 측 웹페이지에서 브라우저 확장으로 이동하는 것입니다. 이는 문제를 거의 완전히 해결합니다. 보안 관점에서 브라우저 확장은 Java 또는 Python과 같은 해석된 환경 내에서 실행되는 데스크톱 애플리케이션과 거의 동일합니다. 그러나 이는 추가 단계를 추가하는 대가가 따릅니다. 사용자는 서버를 신뢰하는 대신 브라우저 확장을 다운로드해야 하며, 이러한 이유로 blockchain.info와 같은 사이트가 안전한 브라우저 확장 버전을 제공하더라도 대부분의 사람들은 여전히 웹사이트를 사용합니다.
위의 모든 내용은 클라이언트 측 브라우저 Javascript에 대한 비난이 아닙니다. 단지 클라이언트 측 브라우저 Javascript가 서버가 모든 돈을 보유하는 접근 방식보다 그렇게 더 안전하거나 신뢰가 없는 것은 아니라는 것입니다. 클라이언트 측 브라우저 Javascript 암호화 애플리케이션을 작성하는 이유는 보안과 신뢰 외에도 있습니다. 가장 큰 이유는 편리함일 가능성이 높습니다. 브라우저 내에서 더 많은 작업이 이루어질수록 애플리케이션 개발자가 스스로 관리해야 하는 인프라가 줄어들기 때문입니다. 이더 판매 웹앱은 바로 이 이유로 클라이언트 측 Javascript를 사용합니다 (개발의 편리함과 서비스 거부 공격에 대한 강건성). 물론 애플리케이션을 사용할 때 이더리움을 신뢰하고 있지만, 이는 문제가 되지 않습니다. 왜냐하면 어쨌든 플랫폼 개발을 위해 이더리움을 신뢰하고 있기 때문입니다. 따라서 blockchain.info와 같은 제공자를 신뢰하고 있다고 인정한다면, 그들의 클라이언트 측 암호화 사용은 정당하다고 할 수 있습니다. 그러나 다중 서명 제공자에 대해서는 이야기가 완전히 다릅니다…
융합된 다중 서명 지갑
클라이언트 측 보안에 대한 이전 논의는 암호화 프로토콜을 다룰 때 보안의 중요한 요소이자 때때로 잊혀지는 요소인 소스 코드의 보안을 주목하게 만듭니다. 비트코인과 같은 암호화 프로토콜은 이론적으로 신뢰가 필요 없지만, 실제로는 거의 모든 사람이 스스로 코드를 평가할 기술적 능력이 부족합니다. Underhanded C 대회에서 개발된 영리한 exploit의 종류는 소프트웨어가 완전히 공격을 받지 않도록 하는 것이 얼마나 어려운지를 잘 보여줍니다. 따라서 사실상 프로그램의 원저자를 제외한 거의 모든 사람에게 프로토콜은 여전히 일정량의 신뢰를 요구합니다.
다중 서명의 경우, 우리가 하려는 것은 어떤 단일 엔티티에 대한 신뢰의 필요성을 명시적으로 제거하는 것입니다. 일반적으로 다중 서명은 두 가지 방법으로 구현됩니다. 첫 번째는 확장된 2-of-2라고 부르겠습니다. 2-of-2의 기본 개념은 간단합니다. 하나의 키는 사용자가 보유하며, 아마도 비밀번호에서 파생된 브레인 월렛이나 브라우저 저장소 또는 클라이언트 측 애플리케이션에 암호화된 상태로 보관된 무작위로 생성된 키일 수 있습니다. 또 다른 키는 서버가 보유합니다. 사용자가 거래에 서명하고 싶을 때, 그들은 자신의 컴퓨터에서 지갑에 로그인한 다음, 자금을 원하는 목적지로 보내는 거래를 생성하고 개인 키로 서명합니다. 그런 다음 거래는 서버로 전송됩니다. 서버는 사기 탐지 검사를 수행합니다. 예를 들어, 사용자에게 확인 코드를 전화번호로 전송하고 사용자가 입력하도록 요청할 수 있습니다. 성공하면 서버는 거래에 서명하고 이를 전송합니다.
그러나 기본적으로 이 계획은 취약합니다. 컴퓨터가 해킹되거나 비밀번호를 잊어버리면 지갑에 접근할 수 없으며 서버는 아무것도 할 수 없습니다. 마찬가지로 서버를 유지하는 회사가 사고를 당하거나 사라지면 접근할 수 없습니다. 2-of-2의 확장은 이 문제에 대한 패치입니다. 본질적으로, 클라이언트가 새 거래를 생성할 때마다 실제로 두 개의 거래를 생성합니다: 하나는 원하는 대로 자금을 보내고, 첫 번째가 완료된 후 나머지 자금을 사용자가 제어하는 백업 주소로 보내는 두 번째 거래입니다. 서버는 두 거래 모두에 서명하지만 첫 번째 거래만 게시합니다. 두 번째 거래는 사용자가 서버가 사라지더라도 자금을 회수할 수 있는 방법이 있도록 반환됩니다. 주소는 2-of-2이므로 서버는 사용자의 동의 없이 해당 거래를 무효화할 수 없습니다. 한 가지 유의해야 할 점은 서버가 거래에 서명하는 첫 번째 엔티티여야 하며 두 번째가 아니라는 것입니다. 그렇지 않으면 서버가 악의적으로 첫 번째 거래만 서명하고 두 번째 거래는 서명하지 않으며 사라져 사용자가 영구적으로 중간에 남겨질 수 있습니다.
두 번째 계획은 간단한 2-of-3입니다. 세 개의 키가 있습니다: 사용자의 키, 서버의 키, 그리고 안전한 오프라인 위치에 보관된 백업 키입니다. 위와 마찬가지로 사용자가 서명하고, 서버는 사용자의 전화로 확인 코드를 전송하고, 사용자가 컴퓨터에서 코드를 입력하면 서버가 서명합니다. 그게 전부입니다. 비밀번호를 잃어버리면 백업 키와 서버의 키를 사용하여 새 지갑으로 거래를 보낼 수 있습니다. 사용자가 해킹당하거나 서버가 해킹당하면 공격자는 여전히 3개 중 1개만 가지고 있으며, 서버가 악의적이거나 사라지면 그들은 3개 중 1개만 가지고 있고 사용자는 3개 중 2개를 가지고 있습니다. 2-of-2의 경우에도 유사한 논리가 적용되지만, 사용자가 키를 잃어버리거나 서버가 사라지는 경우는 비상 거래를 적용하여 처리됩니다. 따라서 우리는 단일 실패 지점이 없는 다중 서명 설정을 생성하기 위한 두 가지 약간 다른 그러나 많은 면에서 동등한 프로토콜을 가지고 있습니다…
… 소프트웨어 코드를 생각하기 시작할 때까지. 인기 있는 다중 서명 지갑 중 하나인 BitGo는 현재 주로 클라이언트 측 Javascript 웹 애플리케이션으로 자신을 소개하고 있습니다. 따라서 우리는 blockchain.info를 분석할 때 사용했던 동일한 분석을 사용하여 BitGo를 분석할 수 있습니다 (참고: 나는 BitGo를 특별히 비난하는 것이 아닙니다. 그것은 단순히 가장 저명하고 자금이 잘 지원되는 것 중 하나일 뿐이며, 다른 대안들도 일반적으로 정확히 같은 방식으로 작동합니다). 공격자가 BitGo의 서버를 장악하면 사용자가 결함이 있는 웹 애플리케이션을 제공받을 수 있는 능력을 갖게 됩니다. 또한 공격자가 BitGo의 서버를 장악하면 두 번째 서명을 적용할 수도 있습니다. 따라서 BitGo는 여전히 단일 실패 지점입니다.
이제 (1) BitGo는 신뢰할 수 있는 회사이므로 그들이 악의적으로 행동할 가능성이 낮고 (2) 다중 서명의 존재는 공격자가 BitGo를 두 가지 방식으로 해킹해야 한다는 것을 의미한다고 합리적으로 주장할 수 있습니다. 그러나 이는 중앙 집중식 서버 측 지갑이 사용자가 키를 저장하도록 하는 복잡성 없이도 동일한 보장을 달성할 수 있다는 주요 요점을 우회하지 않습니다. 따라서 이러한 클라이언트 측 브라우저 다중 서명 지갑 설정은 완전히 암호 경제적 보안 극장으로 간주될 수 있습니다. 이는 BitGo가 안전하지 않다는 것을 의미하는 것이 아닙니다. 대부분의 대안과 비교할 때 좋은 선택입니다. 오히려 이는 “다중 서명” 측면이 일부 사람들이 생각하는 것처럼 정확한 보안 보장을 제공하지 않는다는 것을 단순히 의미합니다.
브라우저 Javascript와 다중 서명을 결합하는 것이 그렇게 문제가 되는 철학적 이유는 브라우저 기반 Javascript 다중 서명 지갑 제공자와 많은 데스크톱 기반 제공자가 프로토콜 관점에서 단일 실패 지점에 면역이 되는 프로토콜을 설정하고 있지만, 동시에 프로토콜에서 클라이언트와 서버라는 두 가지 역할을 수행함으로써 그 이점을 즉시 희생하고 있다는 점입니다. 이 문제는 근본적인 것처럼 보이며, 클라이언트가 모든 상호작용에 얼마나 중요한지 고려할 때 아마도 해결할 수 없는 문제일 것입니다. 위에서 보았듯이 소프트웨어를 다운로드하는 방법에 관계없이, 모든 코드의 각 줄을 적절히 검토할 시간이 없다면 제공자를 신뢰하고 있는 것입니다. 처음에는 이 문제를 피할 방법이 없는 것처럼 보입니다. 그러나 이제 우리는 해결책이 있으며, 그 해결책은 다시 다중 서명에 있습니다 – 이번에는 올바르게 수행된 다중 서명입니다.
융합되지 않은 다중 서명
내가 생각하는 올바른 방식으로 다중 서명을 구현한 실제 사례는 CryptoCorp에서 구축하고 있는 것입니다. CryptoCorp의 다중 서명 접근 방식은 근본적으로 다릅니다. 인터페이스와 보안 제공자를 동일한 패키지의 일부로 취급하려고 하는 대신, CryptoCorp는 인터페이스의 역할을 일반화하고 추상화하여 핵심 제공 사항을 보안 제공자만으로 만듭니다. 즉, CryptoCorp는 서명 오라클 서버를 위한 고급 기능과 알고리즘을 개발하는 데 대부분의 자원을 할애하고, 다른 지갑 제공자가 그들과 통합하여 호환 가능한 인터페이스를 제공할 수 있도록 합니다. 3월 텍사스 비트코인 컨퍼런스에서 CryptoCorp는 수정된 Electrum 지갑의 작동 프로토타입을 보여주었으며, 현재 그들의 서버에 대한 지원 통합을 돕기 위해 10개 이상의 지갑 제공자와 협력하고 있습니다.
물론, CryptoCorp의 서버가 특별한 이유는 무엇일까요? Google Authenticator로 두 번째 요인 전화 확인을 수행하고 거래에 서명하는 앱은 NodeJS로 며칠 만에 작성할 수 있습니다. 저도 직접 해본 적이 있습니다. CryptoCorp가 빛나는 부분은 사기 거래를 필터링하는 데 사용하는 고급 알고리즘입니다. 커피에 3달러를 지불하나요? CryptoCorp 오라클은 확인 요청조차 하지 않습니다. 노트북에 500달러를 지불하나요? 좀 더 엄격하게 확인할 수 있습니다. 자동차에 50,000달러를 지불하나요? KYC 확인에 가까운 절차를 준비하십시오. 수취인의 주소가 잘 알려진 BitPremier에 속하는 것으로 알려져 있다면, 실수로 잘못된 거래를 요청할 수 있기 때문에 더 적은 번거로움으로 거래를 처리할 수 있습니다. 반면 수취인의 주소가 해커 집단과 연결되어 있다면, 3달러의 거래라도 확인을 요청할 수 있습니다.
그렇다면 왜 CryptoCorp의 접근 방식이 더 나은 것일까요? 위에서 다룬 다중 서명에 대한 일반적인 접근 방식에 대한 비판에서 답은 분명합니다: 오라클을 구축하는 엔티티와 소프트웨어를 유지하는 엔티티가 완전히 분리되어 있습니다. 실제로 CryptoCorp를 사용하면 소프트웨어가 공격자에 의해 완전히 장악되더라도 상대적으로 안전할 수 있습니다. 사용자는 자신이 보고 있는 주소가 합법적인지 확인하기 위해 독립적인 도구를 사용할 수 있으며 (모든 키가 실제로 공격자에 의해 제어되는 가짜 다중 서명이 아님), 클라이언트는 일방적으로 거래를 보낼 수 없으며, 클라이언트가 거래의 출력을 변경하거나 금액을 변경하는 것과 같은 더 미묘한 공격을 시도하면 오라클이 이를 감지합니다. 따라서 실제로 단일 실패 지점이 없으며, 암호화폐의 신뢰 없는 약속이 마침내 달성됩니다.
CryptoCorp가 이러한 일반화되고 고도로 모듈화된 방식으로 작업하는 유일한 회사가 아니라는 점을 주목하는 것이 중요합니다. Ripple의 오라클 기반 스마트 계약 플랫폼인 Codius는 정확히 같은 방식으로 문제에 접근하고 있으며, 소비자 보호 관점에서도 Bitrated가 구매자, 판매자 및 중재자의 개방형 시장을 통해 같은 방식으로 접근하고 있습니다. 그러나 Bitrated는 여전히 브라우저 기반 웹앱이며 클라이언트 측 애플리케이션이나 브라우저 확장, 또는 더 나아가 여러 호환 구현을 가진 프로토콜이 아닙니다.
탈중앙화 친화적인 비즈니스 문화
모든 암호화폐 비즈니스가 CryptoCorp, Codius 또는 Bitrated와 더 비슷해지고 PayPal과 덜 비슷해지는 길은 길고도 험난할 것입니다. 기술 비즈니스 커뮤니티에서는 최종 생태계를 만드는 것보다는 단일 구성 요소를 만들고 “해자”를 구축하여 사용자가 제품을 필수적으로 사용하도록 만드는 강한 압력이 있습니다. 이러한 이상은 강력한 탈중앙화 생태계에 매우 중요한 상품화, 일반화 및 관심사의 분리 원칙과 정반대입니다. 안전한 위치와 독점이 있다면 기업의 이익은 크게 증가하지만, 안전한 암호화폐 애플리케이션의 세계에서는 모듈화되고 쉽게 교체할 수 있는 것이 핵심입니다.
그러나 CryptoCorp는 “그냥 서명 오라클”이라는 낙인을 극복하고 정말 정말 좋은 서명 오라클이 되어 이 장벽을 극복했습니다. CryptoCorp와 협력하는 지갑들도 동일한 방식으로 해왔습니다. 심지어 전 세계에 수백 개의 거래소가 있는 궁극적인 상품 비즈니스인 거래소조차도 여전히 자신을 차별화할 수 있습니다. Bitrated와 같은 서비스에서의 중재의 경우, 중재자는 다양한 산업에 전문화하거나 서로 다른 상업적 규범(예: 제품 품질에 대한 수용 가능한 기준, 소비자가 구매 계약을 읽어야 하는 정도 등)을 따를 수 있으며, 더 낮은 수수료를 부과할 수 있는 잘 최적화된 위험 모델을 가질 수 있습니다.
또한 다중 서명 오라클을 운영하는 것이 비즈니스일 필요는 없을 것입니다. DNS 서버와 마찬가지로 이 작업은 단순히 상품화되어 대기업, 비영리 연구 그룹 및 취미로 하는 사람들의 조합에 의해 수행될 수 있습니다. 이러한 상황은 바람직할 수 있으며, 각 노드를 운영하는 각 엔티티는 안정적인 독립적인 수입원을 가지며 잃을 평판이 훨씬 더 많기 때문에 오라클이 사라지거나 속이는 일이 훨씬 덜 발생할 것으로 기대할 수 있습니다. 그러나 궁극적으로 커뮤니티가 진정한 탈중앙화를 요구한다면, 시장은 이를 제공하기 위해 스스로 조정될 것입니다. 남은 것은 전환을 완료하기 위한 조직적인 노력입니다.
