<제58차 이더리움 개발자 회의 안건>
- 관련 링크 : https://github.com/ethereum/pm/issues/89
□ 로드맵(https://en.ethereum.wiki/roadmap/istanbul)
ㅇ 이스탄불 하드포크(이하 'HF') 로드맵- 별다른 이견이 없으므로, 다른이들의 제안이나 의견을 앞으로 참고하길 바란다.
- 일부 개발자는 개선 또는 위험제거 등을 위해서 좀 더 빈번한 HF(Smaller HF)를 제안하였다.
- 또한 EIP를 추가, 조정 등은 많은 책임이 뒤따르며 많은 테스트가 동반되어야한다.
- 이스탄불HF에 담길 EIP에 대하여 5월 17일까지는 협의가능하며, 사실 모든 EIP가 HF가 필요하지는 않으므로 더 많은 논의와 테스트를 통해 우선순위를 정하여 HF 포함여부를 정하는 게 좋을 것 같다.
<부연설명> 이스탄불 예상일정(현재 이견이 없음)
- 05월 17일(금) 이스탄불 HF 제안서 접수 확정기한
- 07월 19일(금) 주요 클라이언트 실행 마감기한
- 08월 14일(수) 테스트넷에서의 네트워크 업그레이드*(Ropsten, Gorli, 또는 다른 임시 테스트넷)
* 19.1월 비탈릭이 포크 대신 네트워크 업그레이드라고 부르고, 체인분기가 일어나는 경우만 하드포크라고 부르기를 이더리움 커뮤니티에 제안한 바 있음.
-10월 16일(수) 메인넷에서의 네트워크 업그레이트(=이스탄불 HF)
<이스탄불 HF의 예상EIPs> 자세한 설명은 이전 회의글을 참조
1> EIP1679(https://eips.ethereum.org/EIPS/eip-1679)
- 이스탄불 HF 상황체크용 '메타 EIP'로, 여기서 언급할 EIP들중 '선임 EIP'라고 할 수 있다.
- 이 메타 EIP는 '이스탄불'로 불리우는 이더리움HF에 포함된 수정사안들을 구체화하기 위함이며, 아직 세부적인 내용은 없는 상태이나 추후 이스탄불HF윤곽이 들어나면서 내용이 추가될 예정이다.
2> EIP 1829(https://eips.ethereum.org/EIPS/eip-1829)
- 타원곡선선형조합에 대한 프리컴파일(Precompile for Elliptic Curve Linear Combinations)이다. '이더리움 트랜잭션에 디지털 서명시, 송신자는 그 트랜잭션(거래)에 대한 진위를 수신자에게 확신시킬때 필요한 방정식이 있고, 그것을 사전에 컴파일링하는 방법에 대한 논의'라고 보면 된다.
3> EIP615(https://eips.ethereum.org/EIPS/eip-615)
- EVM을 위한 서브루틴(subroutines) 및 정적 점프(static jumps)다. '서브루틴과 연산기법을 도입하여 성능향상 등 검증의 최적화를 위한 작업'정도라고 보면 된다.
4> EIP1057(https://eips.ethereum.org/EIPS/eip-1057)
- ProgPoW는 특정ASIC이 채굴할수 있는 작업유효간격을 좁히기 위해 고안된 PoW알고리듬으로, ASIC의 향상된 효율성을 반감시키위하여, 상용GPU자원을 최대한 활용되도록 수정하는 것이 ProgPow의 디자인이다.
5> EIP778(https://eips.ethereum.org/EIPS/eip-778)
- P2P연결정보, 즉 노드간 연결을 위한 오픈 포맷을 위한 정의서다. 노드 간 상호작용을 하기위해서는 일종의 '노드발견 프로토콜'이 필요한데, 이것의 목적은 Public Key, IP주소, 포트번호 등을 중계하는 것이다.
□ EIPs(이더리움 개선 제안)
ㅇ EIP1599 - ETH 1.0체인에서의 수수료 시장 변경- 비탈릭의 부재로 다루지 않음(아래 개인논평에서 다룸).
ㅇ 이더리움 네트워크 업그레이드(=하드포크) 창구
- 네트워크 업그레이드에 대한 가이드라인을 수립하여 이더리움 프로젝트를 추진하는데 있어 사회적으로도 기술적으로도 긍정적인 효과를 얻고자 제안하였다.
- 일부 개발자는 이러한 창구를 만드는게 더 많은 제약을 만든다고 하였다. 가령, 기한을 정하는 것 자체가 제약이며 이로 인해 여러 다른 문제점을 불러일으킬수 있다. 여기에 이 창구 제안자는 제약이라고 보기보다는 좀 더 명확한 일정을 잡아서 집중하는게 분명 이점이 있다고 말했다.
<부연설명>
- 본 창구의 목적은 이더리움 네트워크 업그레이드(또는 하드포크)의 표준화를 통해 일종의 프레임워크를 수립하여 네트워크 업그레이드의 규칙성과 예측가능성을 제공하기 위함이다.
- 네트워크 업그레이드 일정은 크게 3가지 범주로 정의된다.
1) 로드맵 네트워크 업그레이드 : 블록체인 네트워크의 전반적인 프로토콜과 생태계를 개선하기 위하여 임의 설정된 것으로, 홈스테드(Homestead), 콘스탄티노플Constantinople) 등이 대표적 사례다. 이것의 일정은 1월 셋째주, 4월 셋째주, 7월 셋째주, 10월 셋째주 중 한 시점을 선택하고 블록시점을 그 선택시점으로부터 4~6주 전에 정한다.
2) 우선순위 네트워크 업그레이드 : 앞선 로드맵 네트워크 업그레이드보다 긴급하나 생태계 등에 위험을 초래하지 않는 업그레이드로, 현재까지 대표적인 사례가 없다. 이것의 일정은 상대적으로 유연하게 선택할수 있되 가급적 매월 또는 분기당 셋째쭈에 시행한다.
3) 중요한 네트워크 업그레이드 : 프로토콜과 생태계에 위험을 초래하는 요인을 처리하기 위한 것으로, 다오포크에 따른 하드포크 등이 대표적인 사례다. 이것의 일정은 별도로 정하지 않고 합의된 즉시 시행한다.
□ 업무별 업데이트
ㅇ State Fees(스테이트 사용료)- 컨트렉트 사이즈, 해시기능 등 그간 업데이트에 대해 공유하였으며, 현재 큰 특이사항은 없지만 eWasm과의 연결도 시도해봐야하지만 아직 eWasm팀으로부터 소스가 없어 좀 더 기다려야겠다.
<부연설명>
- State(스테이트)란 이더리움 노드에 저장된 eth, code, contract 등을 모아놓은 데이터로, 트랜잭션의 유효성 검증 및 결과 확정 역할을 함. 따라서, 스테이트 용량이 클수록 검증시간이 길어진다. 참고로 19.2.11일 현재 이더리움 스테이트 용량은 129GB로, 다른 암호화폐와 비교할때 큰 편이다.
- 이더리움 스테이트는 전년동기 대비 약 3배정도 용량증가를 보였으며, 시간이 흘러 어느시점에 이르러모든 데이터를 저장하는데 부담이 갈 것임. 이에 비탈릭은 2018년 '네트워크 데이터 저장 임대'를 제안한다.
- 우리가 익히 알고 있는 이더 전송 등 이더리움 네트워크를 이용할때 지불하는 일종의 '전송 수수료'와 달리 비탈릭이 제안한 것은 네트워크에 데이터를 저장할때 지불하는 일종의 '저장 수수료'다.
- 현재 개발중인 샤딩(방대한 데이터를 분리, 저장하여 따로 처리하는 방식)이 도입은 수년이상 걸리고, 도입된다해도 근본적인 해결방안이 되지 않기 때문에, 저장데이터 양과 기간에 비례하는 수수료를 내는 것을 제안하였다.
- 더불어, 전체 데이터 용량조절을 위해 용량한도에 다다를수록 수수료가 높아져 신규저장데이터 감소를 유도한다.
- 다만, 데이터 저장이전에 저장기간의 사전설정해야하는 문제, 수수료에 대한 사용자의 부담감 등이 걸림돌임이다.
ㅇ eWasm
- 특이사항 없음
<부연설명>
- 향후 Serenity단계에서 EVM을 웹 어셈블리 기반인 eWasm으로 변경할 계획이다. 현재 EVM은 너무 복잡하고 성능은 떨어지며, 지원되는 프로그래밍 언어와 개발 툴이 제한적인 반면, eWasm은 효율적으로 각종 프로그래밍 언어와 개발 툴을 지원가능하다. 이것은 기존의 EVM에 비해서 솔리디티 외 다양한 프로그래밍 언어로 코딩이 가능(범용성)하고, 빠른 속도로 트랙잭션 처리가 가능(속도향상)하며, 웹어셈블리 개발 커뮤니티의 지원을 그대로 받을수 있다(인적자원).
- Serenity의 과정까지 단기간 개선사항으로 EVM와 하위 호환가능한 eWasm버전(EVM 1.5)을 메인넷에 채택하고 Serenity에서 비컨체인 도입이후 2단계(Phase 2)에서 제대로 된 eWasm(EVM 2.0)이 사용될 예정이다.
ㅇ Pruning/Sync (ETH V64 관련) : 해당없음.
- ETH 와이어 프로토콜이 2015년 도입된 이래 수많은 개선이 있었고, 보다 나은 개선을 위하여 새로운 버전을 제안하였다.
- 현재 ETH V64에 대한 논의가 활발하며, 여러 다른 그룹들과 협업을 통한 아이디어 제시와 논의를 환영한다.
- 이 제안은 쉽지가 않기 때문에, 우선적으로 현재 구현가능한 코딩이나 모듈을 갖고 논의를 한다면, 이스탄불 기한 내 내용을 확정하는데 도움이 될수 있을것이다.
<부연설명1> Pruning & Sync
- Pruning(프루닝)은 소위 가지치기를 통하여 저장공간을 줄여주는 방식이다. 이더리움에서 스테이트는 항상 최신상태만 유지하지 않고 과거 일정기간의 히스토리까지 보관한다. 그 이유는, 노드간 합의가 되어 한 블록이 생성되어도 아직 확정되어 있지 않는 경우, 분기(bifurcated)될 가능성이 있고 분기 발생시 스테이트를 되돌려야(rollback)해야 될수도 있기 때문에, 최종 확정되기전까지는 히스토리가 있어야한다. 이후 일정시간이 지나면 프루닝을 통해 히스토리가 삭제되고 저장공간을 줄여준다.
- Sync(동기화)는 말 그래도 어떤 대상에 맞추는 것을 의미하는데, 블록체인의 노드로 동작하기 위해서 블록데이터를 다운로드하여 싱크를 해야한다.
<부연설명2> ETH v64 와이어 프로토콜 향상 요청
- 기본적으로 이더리움 네트워크에서는 노드 간 어떻게 연결되고 데이터를 주고받게 되는지에 대한 사안임
- 완전분산네트워크를 위한 DHT(Distributed Hash Table) 프로토콜 중 하나인 카뎀리아(Kademlia)를 기반으로 이더리움만의 인코딩방식과 암호화 및 인증기능 등을 추가한 RLPx프로토콜을 통해 P2P 오버레이 네트워크를 구성하고 노드탐색(Node Discovery)을 수행한다. 그리고 이 RLPx를 통해 분산 네트워크 환경이 조성되면, 비로소 ETH 와이어 프로토콜을 통해 실제 블록체인 데이터가 송수신 된다. 이 ETH 와이어 프로토콜이 2015년 도입된 이래 수많은 개선이 있었고, 현재 ETH v64 와이어 프로토콜 개선을 선택하기 위한 논의가 이어지고 있다(세부사항은 여기 클릭 )
ㅇ 시뮬레이션 : 해당없음
ㅇ 이스탄불 및 이더리움 1.x 로드맵 계획 오프라인 미팅(4월 17일~18일 베를린)
- EIP, HF 등 논의에 관심있는 사람들이 점점 더 많아지고 있고 현재 25명이 만나기로 되어있고,
20명 정도는 각자 일정이 있지만 라이브스트리밍을 통해 참여하기로 하였다.
<부연설명>
1) 이스탄불HF의 절차와 시간에 대한 논의
2) State fees, eWasm, EVM 개선 등 다양한 멀티HF 계획에 대한 논의
3) 이스탄불 HF를 위한 기술적 전문가 및 EIP 제안자의 발표
4) 클라이언트 실행 일정 및 유의사항
ㅇ PorgPoW 감사 업데이트 및 Carbonvote.com 비활성화
- Gitcoin(https://gitcoin.co/grants/82/official-progpow-technical-audit-funding)을 통해서 ProgPoW 기술적 감사를 위한 모금을 안내하였고, 모금이 잘 이루어지지 않더라도
감사에 영향이 없을거라고 본다(현재까지 15,000DAI에 육박하는 자금이 모였으며 목표는 50,000DAI이다).
- 또한 몇주전 Carbonvote.com이 셧다운되었으나, 향후 또 활용될수도 있으나 커뮤니티 여론 등 상황을 봐서 결정할 것이다.
<부연설명> Carbonvote.com
- 이는 DAO 하드 포크 당시부터 시작되어 투표자들이 이더를 지갑에 출금하지 않고도 안전한 웹 페이지 방식으로 투표를 실시하게 하는 것이다. 당시, 커뮤니티가 하드포크와 함께 가기로 결정했을 때 훌륭한 참고자료가 되었다. 즉, 이더리움 재단 및 개발진을 위한 이더리움 지침을 제공하기 위한 커뮤니티 주도형 정량적인 참고 프로젝트라고 볼 수 있다.
□ 테스팅 업데이트 : 특이사항없음.
□ 클라이언트 업데이트 : 해당없음.
ㅇ Gethㅇ Parity Ethereum
ㅇ Aleth/eth
ㅇ Trinity/PyEVM
ㅇ EthereumJS
ㅇ EthereumJ/Harmony
ㅇ Pantheon
ㅇ Turbo Geth
ㅇ Nimbus
ㅇ Mana/Exthereum
ㅇ Mantis
ㅇ Nethereum
□ 리서치 업데이트 : 새로운 워킹그룹을 만들어 프로토타입을 만들고 테스트하고 실행시키는 것을 제안하였다.
<개인 논평> 회의 내용 보완 및 이더리움에 대한 시각
ㅇ 수수료를 활용한 블록체인 네트워크 사용 최적화- 비탈릭 부재로 본 사안이 이번 회의시 다뤄지지 않았지만 흥미로운 부분이라 필자가 별도로 설명하겠다. 블록체인 프로토콜 설계시 가장 까다로운 문제들 중 하나는 '어떻게 블록체인에 자금전송 등 트랜잭션의 양과 가격을 조절하는가'이다. 이 문제는 사회, 경제 분야에서 목격되는 '공유지의 비극(Tragedy of the commons)' 또는 '부정적 외부효과(Negative externality)'와 궤를 같이한다.
- 예를 들어보자. 화학공장을 경영하는 사장은 공장을 가동하면서 화학제품을 팔아 이익을 얻지만 그와 동시에 매연, 폐기물 등 주변환경을 해친다. 이 환경오염을 줄이기 위하여 매연정화장치나 폐기물처리장치 등을 설치할수도 있지만 사장은 그러한 큰 틀에서의 전체 편익 및 비용을 고려하지 않기에 그런 장치들을 설치하지 않으며 그 화학제품 구매자들도
공공환경에 해가 되어도 괘념치 않고 구매를 한다. 즉, 생산자와 소비자는 전반적인 편익과 비용을 신경쓰지 않으므로 최적의 생산 및 소비가 달성되지 않는다. 따라서, 부정적 외부효과는 누군가의 활동으로 제3자가 외부비용이 발생하게 되는 문제가 발생한다
- 이러한 부정적 외부효과는 블록체인 영역에서도 목격되며, 그때문에 일종의 공유지인 블록체인 네트워크를 활용시 자금전송, 채굴작업 등 경제활동을 최적화하기 위한 전략들이 필요하다. 여기서 비탈릭은 이더거래 수수료인 개스(Gas) 조절 전략을 활용하여 트랜잭션 양까지 조절하려는 전략을 계획한다.
- 설명을 하자면, 알고리듬을 통한 최소가격(MINFEE)을 도입하여, 네트워크 전체 개스사용이 많아지면 최소가격이 높아지고 개스사용이 적어지면 최소가격이 낮아지도록 하게끔 제안하였다. 가령, 블록에 꽉 차거나 네트워크 병목현상이 발생시 개스사용 증가에 따라 최소가격이 높아질수도 있다.
- 또한, 경매방식을 도입하여 시장논리에 따라 최소가격을 조정하도록 제안하였다. 더 높은 가격을 제시하는 사람에게 해당 경매물품 소유권을 주는 일반경매방식이 아닌 비슷한 속성을 가진 대상을 거래하는 더치경매방식*을 활용하면 블록체인 네트워크 활용이 더욱 최적화 될수도 있다. 가령, 5개의 트랙잭션의 개스비가 1, 3, 5, 7, 9라고 한다면 일방적으로 채굴자는 가급적 모든 트랜잭션을 처리하여 총합인 25개스를 다 챙기려 할것이다. 하지만 더치경매방식에 따라 채굴자는 개스비 5이상의 트랜잭션 3개만 처리하되 그 3개에 대한 각각의 수수료는 기준가격(=최소가격)인 5개스 즉, 15(3*5)개스를 취한다. 이 경우, 1) 채굴자는 특정가격(=최소가격) 이상의 트랜잭션만 처리하기에 수수료 이득을 극대화할수 있고, 2) 사용자는 머리굴릴 필요없이 스스로 생각하기에 본인 거래에 걸맞는 개스비를 설정하면 되어 시간경제적이고, 3) 전체 네트워크에는 부하가 줄어들어 전체 병목현상이 줄어들고 활용성이 높아진다.
* 더치경매(Ducth Auction) : 네덜란드 튤립경매시, 동일한 특성(종자, 색깔) 등을 가진 튤립을 모아서 경매로 매매하는 방식에서 유래한 것으로, 판매자가 점차 가격을 낮추다가 구매희망자가 나오면 그 최초의 매수희망자에게 상품을 판매하는 방식.
- 결국, 최소가격 설정에 따라 채굴자와 사용자 간의 암묵적인 사회적 합의 하에, 공유지인 블록체인 네트워크는 부정적 외부요인에서 다소 벗어나 최적의 거래 환경이 조성하게 된다.
ㅇ 이더리움을 바라보는 눈
- 최근 삼성넥스트 소속 기술담당자가 이더리움에 대하여 1) 대부분 기술자들이 신뢰할만한 소프트웨어 제작에 집중한 나머지 사용자경험(UX)을 무시한 측면이 있고, 2) 이에 이더리움은 대중의 마음을 사로잡지 못하고 커뮤니티 내 권력구조가 생기는 문제가 발생하고 있다고 지적하였다. 또한 비탈릭 역시 이더리움이 3) 확장성, 경쟁플랫폼 등장 등 스마트컨트렉트 생태계에서 주도권을 잃어가고 있다는 사실은 인정하였다.
- 충분히 수긍할만한 지적과 사실이기에 여기에 굳이 반박하고 싶지는 않다. 어쩌면 이오스의 댄라리머가 지적한대로 이더리움이 너무 일찍 나왔고 애초에 제대로 설계되어있지도, 그리고 현재 제대로 제설계되고 있지도 않는다는 말이 옳을수도 있다.
- 이렇듯 이더리움을 바라보는 안팎의 눈은 이더리움을 더욱 의심어린 눈초리로 바라보고 있고 시간 역시 이더리움 편은 아닌것 같아 보인다. 그러면 여기서 이더리움은 무엇을 하고 무엇을 보여줘야할까.
- 사견이지만 여태껏 이더리움이 보여준 개척정신과 장인정신 덕분에 여기까지 올수 있었지만, 앞으로는 색다른 면모를 보여줘야한다고 감히 제언한다. 작년까지만 해도 유사 플랫폼 프로젝트들은 '이더리움 킬러' 기치아래 각자의 강점을 내세웠지만 어느새부터 '차세대 이더리움'으로 각광받는 프로젝트들이 슬슬 나오고 있다.
- 이런 조류속에, 이더리움은 '기술적인 부분에서의 이더리움 2.0'이 아닌 사용자경험을 향상시키고 언제나 최고로 남을거라는 안일함 지양 등 '전방위적인 이더리움 2.0'을 지향해야 맞다고 본다. 깨진 유리창 하나를 방치하면 그 주변을 중심으로 범죄가 확산된다는 '깨진유리창 이론(Broken windows theory)'이 있다. 이더리움 재단도 안팎의 비판을 방치하면 예기치 못한 큰 문제로 이어질수 있다는 점을 명심하면서, 본연의 정체성을 유지하는 범위내에서 색다른 면모를 보여주어 유사 플랫폼과 선의의 경쟁속에서도 그만의 강한 경쟁력을 보여주기를 바란다.
법적 고지 : 본 게시글은, 투자를 위한 정보제공을 목적으로 작성되었기에 투자결정은 신중을 기하여 주시기 바라며, 참고자료를 토대로 본인 판단하에 내용을 추가, 편집 등 작성되었기에 본인의 허락없이 복사, 배포, 편집 등을 할 수 없습니다.
<References>
1) https://medium.com/decon-lab/%EB%B8%94%EB%A1%9D%EC%B2%B4%EC%9D%B8-%EC%BB%B4%ED%93%A8%ED%8C%85-%EC%9E%90%EC%9B%90%EC%9D%98-%ED%9A%A8%EC%9C%A8%EC%A0%81-%EB%B6%84%EB%B0%B0%EB%B0%A9%EB%B2%95%EB%A1%A0-ed572f4f535f
2) https://ko.wikipedia.org/wiki/%EC%99%B8%EB%B6%80%EC%84%B1#%EB%B6%80%EC%A0%95%EC%A0%81_%EC%99%B8%EB%B6%80_%ED%9A%A8%EA%B3%BC
