블록체인 전문 리서치 스타트업 ‘피넥터’ 팀이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
블록체인의 설계
대부분의 블록체인 프로젝트들의 일반적인 해결과제 또는 설계 난점은 다음과 같다.
1) 확장성 (Scalability)
2) 참여자들의 경제적 인센티브 구조 (Cryptonomics that incentivizes all the interested parties to operate)
확장성은 다음과 같은 여러 요소(component)에서의 확장성을 포괄한다.
– 데이터 처리 속도(프로세싱, processing speed)
– 데이터 검증 속도(검증, validation speed)
– 데이터 전파 속도(네트워크, network relay speed)
– 늘어나는 데이터 크기(저장공간, storage)
– 합의구조에 참여하는 노드 갯수(검증인 수, the number of validators)
– 활용 및 응용 프로그램의 다양성(어플리케이션, scalability on codes and applications)
– 온체인/오프체인 거버넌스(on-chain/off-chain governance)
간략히 말해, 위 확장성 요소들이 종합적으로 작용한 결과가 실제 트랜잭션 속도/처리량(TPS/throughput)으로 나타난다고 이해할 수 있다. 또한, 위에서 다루는 확장성 요소들은 단순 처리량이나 처리속도를 넘어, 실제 실생활에서 얼마나 유연하게 작동할 수 있는가의 여부도 나타내게 된다.
많은 프로젝트가 확장성을 해결하기 위해 여러 가지 접근을 시도하지만, 대부분의 경우 위 요소 중 하나 또는 두 개 수준에서만 접근하기 때문에 실제 작동이 가능한 확장성 확보에는 실패한다.
참여자들의 인센티브 구조를 다음과 같이 정리해본다.
1) 이용자가 지불하는 인센티브 (incentive paid by users)
2) 네트워크와 블록체인을 유지하는 노드(검증인)들이 얻는 인센티브 (incentive granted to validators)
3) 블록체인에서 이용자들에게 제공하는 인센티브 (incentive from a blockchain to users)
인센티브가 반드시 사용 수수료나 금전의 형태를 띨 필요는 없으며, 어떤 형태이건 동기부여 및 지속가능한 경제구조를 만들 수 있다면 유효한 인센티브 구조라고 간주할 수 있다. 위 세 가지 요소가 절묘하게 맞아떨어진다면 해당 블록체인의 경제가 작동하게 된다.
이를 이더리움(Ethereum)에 적용해보면 다음과 같다.
1) 이용자가 지불하는 인센티브: 스마트 컨트랙트나 단순한 이체 시 지불하게 되는 수수료
2) 네트워크와 블록체인을 유지하는 노드(검증인)들이 얻는 인센티브: 노드들은 각 블록을 채굴했을 때 얻는 블록발행보상과 이용자들이 지불한 수수료
3) 블록체인 자체에서 구성원들에게 제공하는 인센티브: 이더리움의 경우, Dapp이나 ICO 코드를 작성하거나 작성된 것에 참여하는 것이 이용자들이 이더리움을 통해서 얻을 수 있는 인센티브라고 볼 수 있다. Dapp의 경우, 사용자들이 Dapp을 사용함으로 얻게 되는 효용이 인센티브가 된다.
EVM의 암호경제학적 한계
위 내용에 대한 간단한 이해를 바탕으로, EVM이 가진 다음과 같은 한계들을 살펴볼 수 있다.
1) 실행코드(Opcode)기반의 가스 수수료 부과(Gas Charging) 시스템: 사용자 더 큰 가치에 더 높은 금액을 지불한다. 반대로, 이더리움은 더 큰 가치가 아니라 더 많은 코드에 더 높은 금액을 매긴다.
이더리움에서 블록체인을 기록하고 스마트 컨트랙트를 작동시키기 위한 독립된 환경을 ‘이더리움 가상 머신(EVM, Ethereum Virtual Machine)’이라고 부른다. 이곳에서 스마트 컨트랙트를 작성하고 실행할 수 있다. 이더리움은 튜링완전한 스마트 컨트랙트가 특정 시점이 되면 종료되도록 하기 위해 각 ‘실행코드’당 가격을 매겼다. (DoS-proof) (물론 그 외에도 가스는 여러가지 역할들을 수행한다)
그러나 ‘소프트웨어 단위’나, ‘스마트컨트랙트 단위’가 아닌 ‘코드 단위’로 매겨졌기 때문에, 긴 연산을 요하는 복잡한 컨트랙트는 그에 비례해 가격이 비싸진다. 그러면 단지 더 깔끔하고 효율적으로 코드를 짜면 되지 않을까? 그렇지 않다. 아무리 효율적으로 코드를 짠다고 해도, 몇 개의 opcode들로 가능한 기능과 더 복잡한 수준의 opcode로 가능한 기능들은 구분된다.
일례로 스프레드시트(엑셀)를 사용하는데, 아래의 두 코드를 실행하는 가격이 다른 식이다.
| =sum(A15:B15)
=QUERY({importrange(“1xOX_VLn5xHujoDyBSbqL8Ufdolce”, “Select Col1,Col8,Col9,(Col11*10000) Where Col7 = ‘”&$A$2&”‘ and Col10 = ‘2015’ and “&MONTH(E2)&” = Col13 label (Col11*10000) ””) |
위 두 코드는 길이상으로 보면 차이가 크지만, 사용자 입장에서는 계산결과를 알려주는 아주 직관적인 절차이므로 양 코드가 가격이 다르다는 점은 이해할 수 없다.
사용자 입장에서는 더 많은 코드가 있어서가 아니라, 더 큰 가치를 지녀야만 더 높은 금액을 지불하는 것이 정당화된다. 반대로, 이더리움은 더 큰 가치가 아니라 더 많은 코드에 높은 금액을 매긴다.
*논의점: 시장 중심적으로 그리고 스마트 컨트랙트 단위로 가격을 매기는 장터 개념이 필요할 수 있음
2) 경쟁방식의 검증인 블록생성과 이기적 검증인: 검증인의 입장에서는 모든 것이 수수료 수익이기 때문에 수익성을 기준으로 Dapp 실행을 줄세우기한다. 낮은 수익성/가치를 창출하는 Dapp은 영원히 실행되지 못할 수 있다.
위의 설명처럼, 수수료를 지불하는 측은 이용자다. 그러나 해당 서비스를 실행하는 측은 검증인이다. 안타깝게도 검증인들은 각 수수료가 어디에서/어떻게/왜 지불되는지에는 관심이 없다. 여러가지 프로젝트들이 다양한 가치와 기능을 표방하며 다양한 컨트랙트를 통해 경쟁하겠지만, 검증인들의 입장에서는 단순히 수익성이 높은 순서대로 줄세우기할 뿐이다.
즉, 특정한 Killer App이 생겨나서 다른 App보다 높은 가치를 창출하는 경우, 낮은 수준의 수익성을 생성하는 App의 경우 거의 실행되지 않거나 영원히 실행되지 못할 수도 있다. 현재 제대로 작동하는 App이 존재하지 않고 있기 때문에 이 현상을 목격할수는 없지만 미래에 발생할 수 있다. 비슷한 예로, ICO시기마다 ICO가 주는 높은 가치(수수료)로 인해 검증인들이 ICO와 관련된 스마트 컨트랙트만을 실행하다가 정작 일반 이체들은 컨펌이 미뤄지는 상황은 쉽게 목격할 수 있다.
낮은 수준의 수수료 가치만을 생성하는 App들은 기능과 의미가 아무리 좋더라도 실행되지 못할 가능성이 있다. 이를 단순히 분산처리 네트워크를 이용해 해결하려는 시도들이 있지만, 기술적인 확장성 확보만으로 해결 가능한 이슈는 아니다.
*논의점: 사용자와 컨트랙트 실행자를 부분적으로 동일하도록 설계하거나, 가스 수수료 부과 시스템 자체를 뒤엎어야 함. 스마트 컨트랙트를 수수료로 줄세우기하여 실행할 수 있는 권한을 검증인에게서 빼앗고, 업무를 일부 랜덤으로 할당하는 개념이 필요할 수 있음
3) 여러가지 Dapp의 상호호환성: 상호호환되는 Dapp들이 독립된 경제구조를 가지고 있을 경우, 사용하는 모든 Dapp에 일일이 따로 금액을 중복하여 지급하게 된다. 반면, 이용자 입장에서는 단일한 서비스일 뿐이기 때문에 납득하기 어렵다.
수많은 Dapp들이 런칭되고 있고 주장하는 기능들도 다양하다. 여러가지 Dapp들이 상호호환되어 함께 작동할 것이라는 주장들이 있다.
예를 들어 이런 식이다. (아주 허술한 예)
어떤 특정한 서비스가 다음과 같은 기능을 요한다.
-인증 (Civic)
-토큰 거래 (EtherDelta)
-예측시장 베팅 (Augur)
-평판 (Monetha)
-SNS (Akasha)
인증을 한 사람들을 대상으로 예측시장 베팅에 성공하면, 토큰 거래를 통해 보상을 주고 이를 평판과 SNS에 기록으로 반영해주는 식이다. (소셜겜블 서비스와 유사)
이 5가지 기능이 독립적인 Dapp과 독립적인 인센티브 구조에 의해 작동한다고 가정하면, 사용자 입장에서는 하나의 서비스를 위해 5번의 수수료를 지불해야 한다. 있을 수 없는 일이다.
사용자 입장에서는 5개의 구성요소들에 전부 수수료를 지불하느니, 해당 기능들이 이미 한 번에 다 포함되어 있는 단일한 서비스를 사용할 가능성이 높다. 여러 개의 Dapp을 합칠 호환시킬 필요 없이, 여러 기능이 들어간 하나의 서비스를 만들면 기존의 Dapp들을 필요 없어진다. 어차피 오픈소스이므로 그냥 5가지를 하나에 복사하여 새로 만들고 서비스하면 된다. (물론 Augur과 같이 해당 서비스가 ‘Reporter’와 같은 자체적인 검증인 세트가 있어야만 작동하는 경우는 예외)
앞으로 실제 서비스가 상용화 수준으로 발전하면서, 현재 존재하는 대부분의 Dapp들 서로 통합되거나 더 완결된 구조를 가진 대체재에 의해 사라질 가능성이 높다.
현재의 Dapp 상호호환성은 허구에 가깝다. 일부 솔루션이 사용되고 있으나, 극소수이고 해당 Dapp이 직접 사용되는 것이 아니라, Dapp 코드만 사용 경우가 많다.
4) 공격비용과 사용비용 딜레마: 이용자들을 위해서는 수수료가 낮아야 하고, 공격자들을 막으려면 높아야하는 딜레마다.
공격자와 사용자가 누구인지 구분할 수 없고, 공격자와 사용자에게 동일한 수수료 구조가 적용되기 때문에 발생하는 문제이다. 단순한 이체기능을 사용하더라도, 코드가 완전히 동일하다면 사용자와 공격자를 구분하는 것은 불가능하다. 동일한 행위에 대한 다른 의도를 읽기는 어렵기 때문이다.
비트코인이 이체네트워크 또는 화폐와 같은 결제수단으로 이용되기 어렵다는 전망은 비트코인의 이체 수수료가 100원 단위를 넘어가면서 제기되어왔다. 즉 높은 수수료는 사용성을 해친다. 수익성을 따지지 않고 일반사용자들만을 생각한다면 수수료는 낮을수록 좋다. 그러나 수수료가 낮으면 DoS공격에 취약해진다. 즉 공격자들이 실제 서비스를 이용하기 위해서가 아니라 네트워크 자체를 마비시키기 위한 목적으로 대량은 트래픽을 만들어내는 식이다. 이 경우, 실제 이용자들이 이용하는 서비스는 중단된다.
이 문제는 이더리움이 비트코인과 같이 특정 기능만을 수행하는 것이 아니라, 예측할 수 없는 다양한 기능들을 구현할 수 있도록 해놓았기 때문에 발생한다. 또한 해당 기능들이 가진 유일한 제약은 특정 코드를 사용하면 특정 액수의 가스를 지불해야한다는 것이므로, 이용자가 지불해야하는 가스비용과 동일하다. 즉, 서로 다른 필요를 단일한 방식(가스)으로 제어하고자 했기 때문에 발생한 딜레마이다.
이용자들을 위해서는 수수료가 낮아야 하고, 공격자들을 막으려면 높아야 한다. 현재의 수수료 구조에서는 공격비용이 매우 저렴하다. 이더리움이 공매도나 선물거래가 생긴다면 이 부분은 중대한 문제가 될 수 있다. 의도적인 공격을 통해 네트워크를 마비시키고 가격을 하락시켜 수익을 얻을 수 있기 때문이다.
수차례의 DoS공격이 있어왔지만, 지금까지는 공격자들이 상대적으로 저렴한 방법을 찾아서 낮은 비용을 지불하면서 높은 작업량을 네트워크에 전가하는 방식을 사용해왔다. 그러나 그렇게 영리한 방법을 찾지 않아도, 공매도 시장이 열린다면 낮은 수준의 공격만으로 충분한 이익을 얻을 수 있는 경제구조가 확보될 수 있다.
공격예시1 – EXTCODESIZE opcode 취약점을 이용한 방법 (링크)
공격예시2 – Transaction Spamming 방법(링크), 여기에서 공격자는 불과 350만원 가량의 가스비용을 들여 몇 주간의 네트워크 속도에 영향을 주게 된다.
이더리움 가격은 기술적 실패나, Dapp해킹 또는 DoS공격 등이 발생했을 때 지속적으로 영향을 받아왔는데, 이는 암호화폐 시장이 전통적 요소들에 더해 기술적 요소에도 많은 영향을 받는다는 점을 암시해준다.
블록체인 2.0의 해결과제
위의 문제들은 EVM의 설계에 내재된 문제이며 이를 해결하기 위해서는 EVM자체를 바꿔야 하는데, 이더리움의 정체성을 EVM으로 믿는 사람들이 많은 가운데서 EVM의 수정은 사실상 다른 프로젝트가 되는 것으로 이해할 수 있다. (정작 이더리움 재단의 개발자들은 정체성을 지키는 것보다는 새로운 솔루션 자체에 더 관심이 많은 분위기)
물론 이 부분들은 단순히 EVM만의 문제는 아니며, 블록체인2.0을 표방하는 플랫폼 형태의 대부분의 프로젝트들이 가지고 있는 문제다. EOS, Qtum, NEO, Agrello, Waves, Tezos 등이 유사한 고민을 공유하고 있다. 다만, 다른 프로젝트들의 경우 튜링 완전성을 없애거나, ‘형식 검증(formal verification)’ 가능한 스마트 컨트랙트 템플릿을 대량으로 제공하는 등의 방법들로 한계를 완화시키고 있다. 위 프로젝트들 중 일부는 이더리움의 스마트 컨트랙트가 보장하지 못하는 ‘결정적 실행성(determinism of executions)’을 시스템적으로 보장하는 것에 집중하기도 한다.
필자를 포함해 많은 사람들은 이러한 문제들에 대해 2년여에 걸쳐 고민해왔고, 여러가지 방법으로 해결책을 논의해왔다. 이를 해결하고자 하는 프로젝트들도 하나씩 생겨나고 있는 단계이다. 아직도 업계는 많은 연구가 필요하다.
[fbcomments url=”http://www.mobiinside.com/kr/2017/11/21/blockchain-evm/” width=”100%” count=”off” num=”5″ countmsg=”wonderful comments!”]
