이번 주 상하이에서 열린 이더리움 재단의 Devcon2 회의와 동시에 이더리움 네트워크의 주요 부분이 중단되었습니다. 의도적으로 실행하기 어려운 스마트 계약을 이용한 공격으로 보이는 상황에서, 많이 사용되는 이더리움 구현체인 Geth는 완전히 작동을 멈췄고, 또 다른 구현체인 Parity도 문제가 발생했습니다. 공격을 발견한 이더리움 개발자들은 몇 시간 내에 Geth를 위한 핫픽스를 작성하여 문제를 해결한 것으로 보였습니다, 적어도 일시적으로는요. 흥미롭게도, 핫픽스가 진행되는 동안 Geth와 Parity를 제외한 대체 이더리움 구현체들은 잘 작동하고 있었습니다. Geth를 실행하는 채굴자들로 인해 해시율이 떨어졌음에도 불구하고, 이더리움 네트워크는 이러한 다양한 클라이언트의 대부분 사용자에게 원활하게 운영되었습니다. 이러한 중단 없는 상황은 일부에게 이더리움이 단일 클라이언트가 아닌 여러 상호 운용 가능한 소프트웨어 구현체를 사용하는 것이 옳다는 것을 입증하는 것으로 받아들여졌습니다.
이더리움의 이러한 성공은 비트코인 공간에서 수년간 존재해온 논쟁을 다시 불러일으켰습니다: 대체 비트코인 구현체가 비트코인 네트워크를 강화하는가, 아니면 약화시키는가?
“참조 구현”
비트코인에 대한 대체 소프트웨어 구현체가 바람직한지에 대한 질문은 수년간 논의되어 왔습니다. 이러한 구현체, 즉 클라이언트는 본질적으로 네트워크에 연결되어 그 일부가 되는 컴퓨터 프로그램입니다. 그들의 역할에 대한 논쟁은 비트코인의 역사 초창기로 거슬러 올라가며, 그 당시 커뮤니티는 주로 기술에 관심이 많은 사람들로 구성되어 있었습니다.
첫 번째 비트코인 구현체는 물론 사토시 나카모토의 비트코인 버전으로, C++ 프로그래밍 언어로 작성되었습니다. 이 클라이언트는 나중에 비트코인-Qt로 알려지게 되었고, 현재는 비트코인 코어로 불립니다; 때때로 비트코인의 “참조 클라이언트” 또는 “사토시 클라이언트”라고도 불립니다. 한동안 이것이 유일한 비트코인 구현체였으며, 시간이 지나면서 사토시는 업데이트를 발표했습니다; 즉, 동일한 클라이언트의 약간 다른 버전들이었습니다.
사토시 나카모토 자신은 오직 하나의 비트코인 구현체에만 고수하는 것이 최선이라고 믿었습니다. 그는 대체 구현체가 데이터를 다르게 처리할 수 있다고 생각하여, 서로 동기화되지 않을 위험이 크다고 경고했습니다. 사토시는 이것이 비트코인의 핵심 속성인 블록체인 원장 상태에 대한 모든 사용자의 합의 도달 능력을 저해할 것이라고 경고했습니다.
2010년, Bitcointalk에서 가빈 안드레센과의 논쟁에서 사토시는 주장했습니다.
“나는 비트코인의 두 번째 호환 구현체가 좋은 아이디어가 될 것이라고 믿지 않습니다. 디자인의 많은 부분이 모든 노드가 정확히 동일한 결과를 동기화하여 얻는 것에 의존하기 때문에 두 번째 구현체는 네트워크에 위협이 될 것입니다.”
가빈 안드레센은 나중에 비트코인의 참조 클라이언트의 수석 개발자로 사토시 나카모토를 이어받았으며, 대체 구현체의 바람직함은 무관하다고 답했습니다. 안드레센은 이러한 대체 구현체가 불가피할 것이라고 믿었습니다 — 사토시가 좋아하든 말든요.
그는 다음과 같이 말했습니다:
“좋은 아이디어든 아니든, 누군가는 네트워크를 망치려 하거나 (자신의 용도로 전용하려 하든) 결국 시도할 것입니다. 그들은 기존 코드를 해킹하거나 자신의 버전을 작성할 것이며, 네트워크에 위협이 될 것입니다.”
첫 번째 대체 구현체
사토시 나카모토가 대체 비트코인 구현체를 좋아했는지 여부는 실제로 무관하다는 것이 입증되었습니다. 첫 번째 알트 클라이언트는 비트코인의 발명자가 커뮤니티에서 사라진 직후에 등장했습니다.
이 경향은 2011년에 처음 발표된 libbitcoin에서 시작되었습니다. 아미르 타키가 이끄는 프로젝트인 libbitcoin은 비트코인에 대한 통제를 분산시키고 공격에 직면했을 때 네트워크의 강인성을 높이기 위해 사토시 클라이언트에 대한 대안을 제공하기 위해 설계되었습니다.
타키는 그의 동기를 리브비트코인 선언문에서 설명하며 다음과 같이 썼습니다:
“여러 지갑과 구현체가 있는 다양화된 비트코인은 강력하고 순수한 비트코인입니다. 네트워크의 무결성을 보호하기 위해서는 단일 실패 지점을 제거해야 합니다. 모든 곳에서 동일한 소프트웨어 코드로 이루어진 비트코인은 동일한 약점을 공유하며, 동일한 공격에 취약합니다. 단일 병원체는 유전적으로 동질적인 집단을 전멸시킬 수 있습니다. 그리고 중앙 집중화된 소프트웨어는 그 소프트웨어 코드의 개발을 통제하는 사람의 요구에 취약합니다.”
그 후 얼마 지나지 않아 더 많은 대체 구현체들이 등장했습니다. 마이크 헌의 bitcoinj가 다른 프로그래밍 언어(Java)로 작성된 첫 번째 비트코인 클라이언트였고, 제프 가르직은 picocoin을, 타마스 블루머는 Bits of Proof를 출시했습니다.
2013년에는 구글의 프로그래밍 언어 “Go”로 작성된 비트코인 구현체인 Btcd가 소개되었습니다. Btcd의 출시는 당시 비트코인 매거진의 작가인 비탈릭 부테린이 쓴 기사에서 다루어졌습니다.
타키의 다양한 생태계에 대한 호소를 반영하여, 부테린은 다음과 같이 썼습니다:
“[T] 프로토콜의 깊이로 들어갈수록 단일 문화가 되어가며; 하지만 단일 문화는 위험합니다. 만약 널리 사용되는 구현체가 하나뿐이라면, 업그레이드에서 예기치 않은 버그가 나타나거나 사라질 경우, 비트코인 블록체인이 본질적으로 두 개로 나뉘게 될 수 있습니다. 두 프로토콜 버전이 어떤 거래와 블록이 유효한지에 대해 이견이 생기기 때문입니다.”
이 시점에서 안드레센은 비트코인 코어의 수석 개발자로서의 역할을 맡고 있었습니다. 사토시 나카모토와의 논쟁 당시보다도 더, 안드레센은 여러 구현체가 비트코인 생태계를 강화할 것이라고 믿게 되었습니다.
비트코인 재단을 위한 블로그 게시물에서 그는 다음과 같이 썼습니다:
“다양성은 좋은 것입니다. 다양한 상호 운용 가능한 비트코인 프로토콜 구현체는 소프트웨어 버그, 서비스 거부 공격 및 취약성에 대해 네트워크를 더욱 강력하게 만듭니다.”
이후, 점점 더 많은 비트코인 구현체들이 비트코인 네트워크에 연결되었으며, 대부분은 자신만의 프로그래밍 언어로 작성되었습니다.
비판
비트코인 구현체의 수가 증가하는 것은 다수 클라이언트 접근 방식의 성공처럼 보일 수 있습니다. 그러나 비트코인 네트워크의 대부분은 여전히 “참조 클라이언트”인 비트코인 코어와 그 버전들에 의해 지배되고 있습니다. 현재까지 완전한 재구현은 사용자, 기업, 특히 채굴자들 사이에서 상대적으로 큰 반향을 얻지 못한 것으로 보입니다.
2015년, 비트코인 개발 메일링 리스트에서 libbitcoin 개발 팀에 대해 비트코인 코어 개발자 피터 토드는 그 이유를 설명했습니다. 간단히 말해, 사용자, 기업 및 채굴자들은 비트코인 프로토콜을 따르는 소프트웨어가 필요합니다. 그리고 비트코인 프로토콜은 토드가 주장하듯이 사토시 클라이언트에 구현된 (일부) 코드로 정의됩니다. 다른 코드는 — 의도치 않게 — 다른 프로토콜을 따를 수 있으며, 비록 그것이 아직 눈에 띄지 않더라도요.
“합의에 중요한 사토시 유래 소스 코드는 기계가 읽을 수 있고 실행할 수 있는 프로토콜 *명세*입니다.”라고 토드는 썼습니다. “합의 코드를 재구현함으로써 — 프로토콜 명세를 다시 작성함으로써 — 당신은 비트코인 개발의 정치적 과정에서 벗어나게 됩니다. 당신은 비트코인을 전혀 분산화하고 있지 않습니다 — 당신은 참여하지 않음으로써 비트코인의 중앙 집중화에 기여하고 있습니다. 사실, 당신이 libbitcoin에서 구현한 것은 비트코인 프로토콜이 아니며, 채굴자들에 의해 채택되지도 않고 진지한 상인 및 거래소에서 사용되지도 않을 것입니다 — 그것이 진정한 정치적 권력의 원천입니다.”
다른 개발 메일링 리스트에 글을 쓰면서, 토드는 이 논리를 통해 사토시 유래 소스 코드의 버그조차도 프로토콜의 일부로 간주해야 한다고 주장했습니다 — 즉, “버그 없는” 대체 소프트웨어 구현체는 그 경우 동일한 프로토콜을 실행하지 않는다는 것입니다. 대체 구현체가 실제로 비트코인 프로토콜을 실행하려면 “버그 대 버그 호환”이어야 합니다.
따라서 토드는 개발자들이 코드 기반을 완전히 재구현하기보다는 비트코인 코어를 포크하고 그 코드 기반을 자신의 필요에 맞게 조정해야 한다고 주장했습니다. 토드 자신은 그의 Replace-by-fee 포크를 위해 정확히 그렇게 했으며, 비트코인 코어 개발자 BtcDrak와 Luke Dashjr도 비트코인 코어 포크인 Bitcoin Addrindex와 Bitcoin Knots를 유지하고 있습니다. (지난 1년 동안, 비트코인의 블록 크기 제한을 늘리려는 개발자들이 Bitcoin XT, Bitcoin Classic 및 Bitcoin Unlimited를 출시하면서 유사한 경향이 나타났습니다 — 비록 이러한 포크는 실제로 특정 조건에서 새로운 프로토콜로 분리되도록 설계되었습니다.)
반비판
물론, 토드의 주장은 그 자체로 비판을 받았습니다.
예를 들어, 대체 구현체가 자신의 네트워크로 포크될 위험이 있다는 점을 인정하면서도, Btcd 개발자 데이브 콜린스는 비트코인 네트워크가 이미 사토시 클라이언트의 여러 다른 소프트웨어 버전으로 구성되어 있다고 지적했습니다. 중요한 것은, 동일한 클라이언트의 이러한 다양한 버전도 마찬가지로 다른 네트워크로 포크될 수 있으며, 실제로 과거에 그렇게 해왔다는 것입니다.
따라서 콜린스는 동일한 클라이언트의 다양한 버전과 대체 클라이언트 간에 근본적인 구분이 없다고 주장했습니다. 그의 컨포멀 블로그에서:
“현재 어떤 두 개의 비트코인 소프트웨어 버전, 비트코인 코어의 두 개의 다른 버전, 대체 구현체의 두 개의 다른 버전, 비트코인 코어의 버전과 대체 구현체의 버전, 또는 심지어 서로 다른 컴파일러 버전으로 빌드된 동일한 비트코인 코어의 두 개의 복사본이 정확히 합의에 도달하고 있다는 것을 보장할 방법은 없습니다. 그렇게 하는 것은 믿을 수 없을 정도로 어렵고 불가능에 가깝습니다. 문제는 구현에 독립적입니다.”
현재 libbitcoin은 에릭 보스큘이 이끌고 있습니다. 놀랍지 않게도, 보스큘은 콜린스의 의견에 동의합니다. 그리고 보스큘은 버그가 구현체의 합의 인코딩의 일부라는 토드의 입장을 인정하면서도, 이는 비트코인 프로토콜을 정의하는 특정 구현체가 없어야 한다고 주장합니다.
“합의에 영향을 미치는 모든 코드는 합의의 일부입니다.”라고 보스큘은 비트코인 매거진에 말했습니다. “하지만 이 코드의 일부가 네트워크를 중단시키거나 좋지 않은 일을 한다면, 그것은 수정이 필요한 버그라고 불리지만, 그 수정은 합의에 대한 변경입니다. 버그가 합의이기 때문에, 수정은 포크입니다. 따라서 단일 구현체는 개발자에게 너무 많은 권한을 부여합니다. 네트워크를 중단시키면서 어떤 비밀 회의가 새로운 합의를 도출하는 것은 전적으로 권위적입니다.”
이더리움
이번 주 이더리움의 Geth 노드의 실패는 소프트웨어 구현체의 한 세트가 중단되는 첫 번째 명확한 실제 사례를 제시하며, 대체 구현체 — 그리고 따라서 네트워크 자체 — 는 계속 운영될 수 있었습니다.
물론, 이더리움 생태계 내의 이러한 다양성은 이더리움 창립자인 비탈릭 부테린의 비전 덕분입니다 — 같은 부테린이 비트코인 매거진의 작가로서 더 다양한 비트코인 생태계를 지지했습니다. 처음부터 이더리움은 특정 참조 구현체 하나가 아닌 여러 다른 클라이언트와 함께 시작되었습니다.
그러나 모든 사람이 Geth 노드가 중단되는 동안 이더리움 네트워크가 계속 운영되는 것이 바람직하다고 동의하는 것은 아닙니다. 피터 토드는 실제로 네트워크의 모든 노드가 동일하게 행동하는 것이 더 나았을 것이라고 주장하며, 심지어 그것이 모두 중단되는 것을 의미하더라도요.
그는 비트코인 매거진과의 인터뷰에서 다음과 같이 설명했습니다:
“기본적으로 거래는 매우 간단합니다. 여러 구현체가 존재하면 네트워크의 가용성이 우선시되지만, 문제가 해결되는 동안 네트워크를 사용하는 것은 꽤 위험한 일이었습니다. Parity 노드는 정상 속도로 블록을 전파하지 못해 고아 비율을 증가시키고 잘못된 확인이 발생할 가능성을 높였습니다. 정상보다 낮은 해시 파워는 51% 공격의 위험을 증가시켰습니다. Geth 수정이 잘못될 수도 있었습니다. 그리고 일반적으로, 사건이 발생하는 동안 이러한 일이 발생했는지 여부는 알 수 없었습니다. 문제가 발생하면 모든 것이 중단되는 것이 가장 안전하며, 이 경우 몇 시간의 다운타임만 있었을 것입니다 — 큰 문제가 아닙니다.”
토드는 Geth 노드가 중단되지 않았다면 상황이 더 나빠졌을 것이라고 믿고 있으며, 대신 서로 다른 거래와 블록을 확인하거나 거부했을 것이라고 말했습니다.
“Geth는 쉽게 다른 체인으로 분리될 수 있었고, 그 경우 문제는 훨씬 더 나빴을 것입니다. 그 경우 실제로 어떤 것이 올바른 체인인지 명확하지 않습니다.”라고 그는 말했습니다.
물론, 여기서 libbitcoin의 에릭 보스큘은 동의하지 않습니다. 비트코인 매거진과의 인터뷰에서 보스큘은 토드가 문제를 잘못된 관점에서 접근하고 있다고 믿습니다. 프로토콜을 정의하는 소프트웨어 구현체가 아니라, 실제로 거래를 수행하는 사람들이 이 작업을 해야 한다고 보스큘은 말합니다.
“‘올바른 체인’은 없습니다 — 사람들이 사용하기로 선택한 것들만 있습니다.”라고 보스큘은 말했습니다. “하나의 진정한 구현체가 합의를 정의하고 그것이 실패하면, 합의는 무엇입니까? 이더리움 네트워크의 사람들이 다른 구현체를 계속 사용했다는 사실은 Geth에 대한 ‘수정’을 작성하는 개발자들이 합의를 재정의할 수 없음을 의미하며, 실제 합의에 부합해야 했습니다.”
미래 전략
앞으로 비트코인 생태계를 더욱 다양화할 수 있는 여러 프로젝트가 진행 중이며 — 아마도 블록체인 분할의 위험 없이도. 적어도 일부는 그렇게 믿고 있습니다.
피터 토드는 공식적인 증명이 미래에 도움이 될 수 있다고 지적했습니다. 비트코인 매거진에 이 개념을 설명하며 그는 다음과 같이 말했습니다:
“기본적으로 공식적인 증명은 코드가 당신이 생각하는 대로 작동한다는 것을 증명하는 수학입니다. 또는 최소한, 코드가 특정 속성을 가지고 있다는 것입니다. 이는 서로 다른 구현체가 실제로 동일한 프로토콜을 따를 것임을 검증하는 데 사용될 수 있습니다. 이는 큰 도약이 아닙니다; 공식적인 증명은 이미 비트코인에서 libsecp256k1 라이브러리의 일부가 올바르다는 것을 증명하는 데 사용되고 있습니다.”
또 다른 유망한 프로젝트는 비트코인 코어 코드 기반에서 파생된 소프트웨어 라이브러리인 libconsensus일 수 있습니다. 2014년에 시작된 비트코인 코어 개발자들의 노력으로, libconsensus는 대체 구현체가 네트워크의 나머지와 합의를 유지하는 데 필요한 코드를 쉽게 채택할 수 있도록 해야 합니다.
비트코인 코어 및 블록스트림 개발자인 호르헤 티몬은 libconsensus의 주요 지지자이자 가장 활발한 기여자 중 한 명입니다. 비트코인 매거진과의 인터뷰에서 티몬은 “비트코인 코어”가 현재 실행 중인 구현체이기 때문에 “구현체가 명세이다”라는 개념이 실제로 문제라고 설명했습니다.
“이는 다른 구현체에 대해 특정한 의미에서 불공정합니다.”라고 티몬은 말했습니다. “그들은 합의 검증을 재구현하는 것에 대해 경고받지만, ‘비트코인 코어 노드 뒤에서 당신의 것들을 실행하라’는 것 외에는 그들에게 주어지는 해결책이 없습니다. 그래서 우리는 비트코인 코어에서 블록을 완전히 검증하기 위해 충분한 코드를 분리하고 있습니다 — 그리고 그 외에는 아무것도 아닙니다. 이는 대체 구현체가 사용할 수 있습니다.”
그러나 libbitcoin의 보스큘은 비트코인의 생태계를 다양화하는 데 libconsensus가 정말로 필요하다고 생각하지 않습니다.
“Libconsensus는 더 다양한 커뮤니티를 만드는 데 도움을 주려는 정직한 시도이며, libbitcoin은 이를 옵션으로 지원합니다.”라고 그는 비트코인 매거진에 말했습니다. “하지만 이는 장기적인 해결책으로는 생존하지 않을 것입니다. 이는 불필요하고, 개발을 복잡하게 하며, 현재는 스크립트 검증 외에는 아무것도 다루지 않습니다. 만약 포크를 초래할 수 있는 모든 것을 다루도록 확장된다면, 이는 노드의 대부분 구현이 될 것입니다. 우리는 libconsensus를 선호하여 우리의 스크립트 코드를 덤프할 수 있지만, libconsensus가 합의에 영향을 미치는 모든 것을 포함하도록 확장된다면, 우리는 무엇을 남기게 될까요? 이는 낙타의 코가 텐트 안으로 들어가는 것입니다.”
보스큘은 덧붙였습니다:
“결국, 이 모든 것은 정말로 무의미한 점입니다. 다른 구현체가 존재하고 네트워크에서 실행되고 있습니다. 이는 멈추지 않을 것이며, 오히려 증가할 것입니다. 여러 구현체에서 합의 규칙이 신뢰성 있게 구현될 수 없다는 생각은 터무니없을 뿐만 아니라 무관합니다.”
*이 이야기는 목요일에 이더리움 네트워크를 괴롭힌 새로운 공격 이전에 작성되었습니다. 그 이야기는 여전히 진행 중입니다.
