<제57차 이더리움 개발자 회의 안건>
- 관련 링크 : https://github.com/ethereum/pm/issues/83
□ 로드맵
ㅇ 이스탄불 하드포크(이하 'HF') 로드맵- 이더리움을 탈퇴한 이전 포크 담당자 애프리쇼든가 일전에 만든 로드맵이 아래와 같으며, 이 로드맵에 큰 이견이 없어 암묵적인 합의가 있는 상태이다.
- 일부 개발자가 이미 이스탄불HF에 포함할 후보EIP들을 제안한 상태이며, 핵심 개발자 회의를 통해 추가 논의가 있을것이다.(그 후보EIP들에 대해서는 이 글 후반부에 대해서 언급하였으니 참고바람)
<부연설명> 이스탄불 예상일정
- 05월 17일(금) 이스탄불 HF 제안서 접수 확정기한
- 07월 19일(금) 주요 클라이언트 실행 마감기한
- 08월 14일(수) 테스트넷에서의 네트워크 업그레이드*(Ropsten, Gorli, 또는 다른 임시 테스트넷)
* 19.1월 비탈릭이 포크 대신 네트워크 업그레이드라고 부르고, 체인분기가 일어나는 경우만 포크라고 부르기를 이더리움 커뮤니티에 제안한 바 있음.
-10월 16일(수) 메인넷에서의 네트워크 업그레이트(=이스탄불 HF)
ㅇ 출시 담당자(Release Manager)
- 캣 허더를 통해 1명이 신청한것 같으며, 추가로 포크 담당자를 신청하기를 바란다.
ㅇ ProwgPoW 업데이트
- 지난번에 논의된대로, ProgPoW 감사를 위한 2가지 구성요인은, 얼마나 ASIC에 대해서 ProgPoW가 (그래픽 카드별로) 구현 시간, 성능 등 얼마나 효율적인가에 대한 벤치마킹이고, 그리고 어떤 프로젝트를 선정하여 펀딩을 할건인지의 판단이다.
- 현재까지 2개의 제안이 들어왔고 (추가로 1개가 추가될수도 있음) 캣 허더*가 가치판단 등을 통해 어떤 프로젝트를 선정하고 그것을 위해 펀딩을 할것인지 결정할것이다.
*이더리움 캣 허더(The Ethereum Cat Herders) : 프로젝트 관리와 같은 기본 안을 개선하여 Ethereum 프로토콜 및 커뮤니티 개선에 전념하는 Etherean의 글로벌 분산형 풀뿌리 커뮤니티(자세한 정보는 여기 클릭 )
- 이스탄불HF에 ProgPoW에 포함시키기 위해서는 우선 감사를 도입하고 그 감사진행을
이스탄불 HF 제안서 접수 확정기한(5월 17일)까지 완료되는지 등 지속적인 감시와 논의가 필요할것이고, 이 사안은 점점 더 민감한 사안으로 간주되므로 우리가 현재 안건으로 다루고 있고 커뮤니티를 주시하고 있는것이다. (ProgPoW는 주기적인 알고리즘 변경으로 ASIC 채굴기에 저항성을 가진다는 게 핵심인데, 빠른 시일 내로 ASIC이 출현하게 된다면 해당 알고리즘을 도입할 가치가 불충분하다는 뉘앙스)
- 일부 개발자는 ProgPoW가 별도의 HF를 통해 시행되어야 한다고 주장하였다. (필자가 볼때, ProgPoW는 그 특성상 해당 알고리듬이 탑재된 하드웨어가 생산에 들어가고 제조되어 배달을 해야하므로, 단순 소프트웨어적 기술 관련인 다른 EIP들과 병행하기에는 이스탄불 HF 지연빌미 제공 등 무리가 있다고 본다).
- 회의에서 논의가 이어지다가 다시 케케묵은 GPU vs. ASIC에 대한 논쟁이 있었고, 결국 ProgPoW에 대한 하드웨어 부분은 그래픽카드 제조사, 시장 등이 할 몫이고, 우리 개발자들은 우리만의 논의와 개발을 통해 진정으로 ProgPoW가 도입할 가치가 있는지에 대해 따져보자고 했다.
- ProgPoW에 대해 확고한 입장이 있는 핵심 개발자가 있지만, 그들이 개발자 회의에 불참하는 이유는, 동의하기 때문이라고 보는 개발자도 있고, 동의하지 않기에 더이상 말하기 싫어서라고 보는 개발자도 있었다.
- ProgPoW에 대한 논의가 계속 이어지자 비탈릭의 제안으로 일단 다음 안건으로 넘어가고 회의 막판에 추가 논의하기로 했다(회의 막판에는 다음 회의에 다룰 내용에 대한 간단한 언급만 함).
□ EIPs(이더리움 개선 제안)
ㅇ EIP 778 (P2P연결정보, 즉 노드간 연결을 위한 오픈 포맷을 위한 정의서)- 이 제안에 대한 대략적인 소개(이 글 후반부에 적어놨음)가 있었고, 개발자간 논의가 이어졌다.
- EIP 778은 이미 다른 2개의 EIP들과 연관이 있지만, 1년넘게 피드백도 없이 그저 제안으로 남겨져있는데, 이번에 다른 EIP들과 연관되지 않는 3번째 관련 EIP를 제출할 예정이다.
- (이번 3번째 제안을 포함해) 3개의 관련 EIP를 한번에 적용시킬지 하나씩 적용시킬지에 대한 논의가 있었고, 기본적으로 이 개선안은 어려운게 아니라서 빠른 시일내에도 적용하여 구현할수 있다.
- 이 개선안에 대해 핵심 개발자들은 관심을 가졌고, 긍정적으로 봐서 추진하는데는 문제가 없어보인다.
□ 업무별 업데이트
ㅇ State Fees(스테이트 사용료)- 담당자가 테스트를 통해 4백만 블록이 넘는동안 스마트컨트렉트를 통해서만 실행 가능한 블록 증명과 (머클)트리의 해시 등을 통한 검증 등에 대하여 발견한 바를 공유하였다.
※ 공용유틸리티인 이더리움에 있어, 스토리지 장기간 사용료를 저렴하게 책정하고자 하며, 이때 책정산식은 'Byte x time'.
<부연설명>
- State(스테이트)란 이더리움 노드에 저장된 eth, code, contract 등을 모아놓은 데이터로, 트랜잭션의 유효성 검증 및 결과 확정 역할을 함. 따라서, 스테이트 용량이 클수록 검증시간이 길어진다. 참고로 19.3월 현재 이더리움 스테이트 용량은 130GB 이상으로, 다른 암호화폐와 비교할때 큰 편이다.
- 이더리움 스테이트는 전년동기 대비 약 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)를 일부 수정하여 사용한다. 이 카뎀리아는
노드 간 거리를 XOR distance로 측정(공개키를 노드ID로 하며, 이 노드ID간 거리를 XOR연산함)하며, 따라서 노드개수를 N개라 할때 각 노드는 log(N)개의 연결만 유지하면 연결가능하다. 쉽게말해, 각 노드는 자기가 아는 노드들 중 가까운 노드와 우선통신함으로써 적은 연결수로도 큰 네트워크 구성이 가능하다(더 쉬운 설명으로, 내가 전주 맛집을 알고싶을때 내 친구들중 전주 출신에게 물어보고 그 전주 출신 친구는 먹는 걸 좋아하는 고향 친구를 나에게 소개시켜주면 결국 진정한 전주 맛집을 알수 있는 원리와 비슷하다)
- 여튼 이 카뎀리아를 기반으로 이더리움만의 인코딩방식과 암호화 및 인증기능 등을 추가한 RLPx프로토콜을 통해 P2P 오버레이 네트워크를 구성하고 노드탐색(NodeDiscovery)을 수행한다. 그리고 이 RLPx를 통해 분산 네트워크 환경이 조성되면, 비로소 ETH 와이어 프로토콜을 통해 실제 블록체인 데이터가 송수신 된다.
- 이 ETH 와이어 프로토콜이 2015년 도입된 이래 수많은 개선이 있었고, 현재 ETH v64 와이어 프로토콜 개선을 선택하기 위한 논의가 이어지고 있다(세부사항은 여기 클릭)
ㅇ 이스탄불 및 이더리움 1.x 로드맵 계획 오프라인 미팅(4월 17일~18일 베를린)
- 지난 1월에 논의된 이후, 4월 17일~18일에 베를린에서 보기로 하였고, 같이 모여서 구글폼으로 된 신청서를 제출하여 참여가능하며, 이 미팅을 통해 아래와 같은 제안 등을 논의할 예정이다.
1) 이스탄불HF의 절차와 시간에 대한 논의
2) State fees, eWasm, EVM 개선 등 다양한 멀티HF 계획에 대한 논의
3) 이스탄불 HF를 위한 기술적 전문가 및 EIP 제안자의 발표
4) 클라이언트 실행 일정 및 유의사항
□ 테스팅 업데이트 : 주요 특이사항 없음
□ 클라이언트 업데이트 : 차례로 간단히 업데이트 내용을 언급함
ㅇ Geth
ㅇ Parity Ethereum
ㅇ Aleth/eth
ㅇ Trinity/PyEVM
ㅇ EthereumJS
ㅇ EthereumJ/Harmony
ㅇ Pantheon
ㅇ Turbo Geth
ㅇ Nimbus
ㅇ Mana/Exthereum
ㅇ Mantis
ㅇ Nethereum
□ 리서치 업데이트 : 시드니에서의 EDCON, 비콘체인, FFG 등에 대한 간단한 논의가 있었음.
□ 기술적 설명과 개인 논평
< 기술적 설명 >ㅇ 이스탄불 여정에 함께할 EIP후보들
- 향후 있을 이스탄불HF에 포함될 개선안들을 나름대로 정리해봤으니 하나씩 알아보기로 하겠다.
<1> EIP 1679 (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)이다. 아래 기술적 내용이 어렵다면 그냥 '이더리움 트랜잭션에 디지털 서명시, 송신자는 그 트랜잭션(거래)에 대한 진위를 수신자에게 확신시킬때 필요한 방정식이 있고, 그것을 사전에 컴파일링하는 방법에 대한 논의'라고 알고 넘어가면 될것같다.
- 현재 EVM은 오로지 ecrecover를 통해 선형적으로 secp261k1을, 두 프리컴파일을 통한 altbn128을 지원한다. 더 많은 곡선을 추가하라는 제안서 초안이 있다. 기존 시스템과의 통합을 위한 쓸모있는 응용 프로그램을 가진 타원형 곡선들이나 영지식증명을 위한 새로 개발된 곡선들이 많다.
- 결론적으로, 이 EIP는 모든 클래스의 커브를 허용할 프리컴파일은 추가하고자 한다.
※ 이 EIP에 대한 블록체인 알쓸신잡 "이더리움에서의 타원의 미학"
이더리움 송금시 발생되는 트랜잭션에는 송신자, 수신자, 송금할 이더리움개수, 수수료, 추가데이터 등이 들어가며, 진위여부 판단시 진짜라는 증거로 '디지털서명'이 필요하며, 1) 송신자만의 고유한 방식(Private Key)으로부터 디지털서명을 추출하여 만들수 있고, 2) 수신자가 그 서명이 송신자것임을 쉽게 확인가능해야 하는데, 이 조건들을 충족하는 디지털서명을 만들수 있는게 '타원곡선'덕분이다.
타원곡선의 방정식은 y2 = x3+ax+b이며, 그래프로 표현하면 다음과 같다.
 |
| < https://crypto.stackexchange.com > |
그래프에서 보시다시피 타원곡선은 x축 중심으로 수평대칭이며, 이 대칭성을 활용하여 '기본포인트'인 G점으로부터 시작하여 나름대로의 방식으로 x축 대칭하면서 대칭회수에 따라 2G, 4G, 8G 등의 '특이포인트'들을 얻을수 있다.
이런 특성을 활용하여, 송신자가 트랜잭션 내 디지털서명을 만들때 Private Key를 타원곡선이 지원해주는 범위안에서 만들수 있으며, 이때 이더리움(비트코인 역시) 블록체인에서 활용하는 타원곡선이y2 = x3+7이며 이 특정 방정식(함수)을 우리는 'secp261k1'이라고 부른다. 이 secp261k1 타원곡선으로부터 만들어진 Private Key는 1에서 n-1까지의 16진수이며 1부터 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140까지 표현된다. 이 Private Key로부터 특정산식(k*G, k는 임의숫자)을 통해 아까언급한 2G, 4G, 8G 등의 '특이포인트'들을 추출할수 있는데 그 값을 'r'이라고 하자. 그리고 'r'값에서 특정산식(k^-1(z+r*Private Key) mod n)을 통해 또다른 '특이포인트'인 's'를 추출할수 있다. 정리하면, 송금자는 트랜잭션과 함께 디지털서명키('r'과 's')을 넣어 수신자에게 송금한다.
추가로 'r'과 's'같은 디지털서명만 갖고도 복구키(값)을 활용하여 송신자의 Public Key를 추출할수 있는데 이 복구키(값)을 'v'라고 하자. 즉 수신자는 송신자로부터 받은 디지털서명키('r'과 's')를 'v'값을 활용하여 송신자의 Public Key를 도출할수 있다. 참고로 'Public Key의 우측40자리' = '지갑주소'이다.
그렇다면 ecrecover은 무엇인가. ecrecover라는 함수는 수신자가 송신자로부터 받은 디지털서명값의 진위여부를 확인하기 위해 필요하며, 반대로 ecsign이라는 함수는 송신자가 디지털서명값을 추출하여 만들기 위해 필요하다. 아울러 altbn128은 일반 자바 스크립트에서 구현하는데 용이한 타원곡선 암호화기법으로, 이더리움에서는 파이썬으로 활용된다.
<3> EIP 615 (https://eips.ethereum.org/EIPS/eip-615)
- EVM을 위한 서브루틴(subroutines) 및 정적 점프(static jumps)다.
- 이 내용은 지난 56차 회의때도 다뤄진 내용이라 낯익을텐데, 역시 아래 내용이 어렵게 느껴진다면, '서브루틴과 연산기법을 도입하여 성능향상 등 검증의 최적화를 위한 작업'정도라고 알고 넘어가면 되겠다.
※ 이 EIP에 대한 블록체인 알쓸신잡 "이더리움에서의 점프의 미학"
블록체인은 자세한 설명과 검증이 필수인데, EVM*설계 상 그것들을 하기 어렵고, 낮은가스비 및 고성능실행 역시 적용이 어렵다. 현재 EVM은 동적 점프**(dynamic jump)를 지원하는데, 어디로 점프할지 스택상 애매하다. 즉, 동적 점프는 코드구조를 모호하게 만들어, 제어분석 및 데이터 흐름분석에 제약이 된다. 결국 이는 최적화된 컴파일의 품질과 속도를 떨어뜨리며, 많은 점프가 코드 상 임의의 점프대상에도 놓일수 있기에, 코드를 통한 경로수는 정적분석의 복잡성과 같이 대상수와 점프수의 곱한수까지 많아질수 있다.
이 경우, 배치시간(deployment time)동안 결정장애가 있을수 있고, 또한 정적 및 공식(formal) 분석에 제약이 된다. 따라서, 정확성 증명, 정적 분석, 컴파일 최척화 등을 저해하는 동적 점프 사용을 지양하고, 이를 대체하기 위한 서브루틴과 몇가지 다른연산을 도입하고자 하며, 이것은 성능향상 등 이점을 제공하면서도, EVM성능한계를 시험할수 있을것이다.
* EVM(Ethereum Vitrual Machine, 이더리움 가상 머신) : 이더리움을 전체를 작동하는 엔진으로, 수많은 토큰과 디앱 등을 책임짐.
** 점프(jump) : EVM의 컨트렉트 함수는 내외부, 재귀 호출 등 여러가지인데, 이 중에서 내부함수를 효율적으로 호출하는 연산코드로 프로그램 카운터(PC)를 이동하여 다른 바이트코드(bytecode)를 실행함.
참고로, 부재 동적점프(Absent dynamic jump)코드는 선형적인 시간에 따라(in linear time) 정적으로 분석하게 해준다. 정적 분석에는 유효성 검사, 최적화, 편집 및 공식분석이 포함되며, 여기에 많은 이점을 제공한다. 그리고 적절한 서브루틴과 부재 동적점프는 EVM을 Solidity, Vyper, LLRM IR 등과 같은 다른 언어의 코드 생성을 가능하게 한다. 결과적으로 선형적인 시간에 따른 배치시간동안 여러 유효성 검증 및 최적화가 가능하다. (세부내용은 여기 클릭)https://github.com/ethereum/EIPs/blob/master/EIPS/eip-615.md
첨언하자면, 나중에 eWasm이 도입되겠지만 그럼에도 어쨌든 현재 가동중인 EVM을 개선될 필요가 있고 근본적으로 동적 점프를 제거할수는 없겠지만 대신에 정적점프를 사용하고 그덕분에 대부분의 언어로 사용자를 이동시킬수 있으며, 결국 이러한 EVM변경 덕분에 wasm으로 쉽게 이동(porting)도 가능할것이다. 이를 위해서, 서브루틴 추가, 정적점프 연산코드 추가, 커뮤니티 교육을 통한 동적점프 사용 빈도 낮추기 등이 필요할것이다.
< 4> EIP 1057 (https://eips.ethereum.org/EIPS/eip-1057)
- 그 유명한 ProwPoW에 대한것으로, 더이상 자세한 설명은 생략,,할까하다가 주요이슈이기에 다시 설명하겠다.
- ProgPoW는 특정ASIC이 채굴할수 있는 작업유효간격을 좁히기 위해 고안된 PoW알고리듬으로, 이더리움네트워크에서 활용되는 상용GPU에 맞추면서도 GPU자원을을 극대화시킨다.
- 현재의 Ethash알고리듬의 경우, 범용 GPU가 메모리 활용시 60%정도만 활용하기에 비효율적인데 반해 FPGA나 ASIC은 이런 비효율적인 메모리 활용을 임의설계하여 메모리 효율성을 높이기 때문에 채굴 관점으로 보면 그 향상된 효율성이 곧 향상된 채산성으로 이어지게 되는 것이다.
- 이에 ProgPow의 필요성이 대두되었고, ASIC의 향상된 효율성을 반감시키위하여,
상용GPU자원을 최대한 활용되도록 수정하는 것이 ProgPow의 디자인이다. 실제로 시중의 AMD, NVIDIA 모델을 통한 테스트를 진행했는데, 해당 모델들의 계산능력과, 메모리 대역폭의 효율성을 높일수 있었다. 다만 Ethash 대비 ProgPow가 해시당 메모리 접근성이 두배에 달하기 때문에 해시레이트가 절반정도로 낮아지는 현상이 벌어지게 된다.
<5> EIP 778 (https://eips.ethereum.org/EIPS/eip-778)
- P2P연결정보, 즉 노드간 연결을 위한 오픈 포맷을 위한 정의서다.
- 노드 간 상호작용을 하기위해서는 일종의 '노드발견 프로토콜'이 필요한데, 이것의 목적은 Public Key(아까 알아본 secp256k1 타원곡선), IP주소, 포트번호 등을 중계하는 것이다. 따라서, 보다 유연한 노드 연결정보를 정의하기 위하여 빠른 암호화와 향상된 프로토콜 업그레이드 처리를 기대할수 있다.
- 여튼 노드 연결정보에 있어 신뢰할만한 업데이트를 제공하여, 노드가 접촉의 끝점(endpoint)을 변경하고 새로운 레코드를 발행하면, 다른 노드들이 그 새로운 레코드를 포한한 모든 레코드들 중에서 어떤 레코드가 더 최신인지 결정하는데 도움이 된다.
< 개인 논평 >
ㅇ 이더리움 개발의 현재와 미래에 대한 생각
- 바로 앞선 기술적 설명부분이 생각보다 길어져 이번 논평은 최대한 간단히 하겠다(그런데 논평 역시 쓰다가 길어질것 같은 기분이다).
- 이번 회의도 역시 가장 큰 안건은 'ProgPoW'였다. 제3자에 의한 감사는 도입하기로 하였고, 그 감사의 결과에 따라 ProgPoW의 도입여부가 결정난다. 이 이슈에 대해서는 이미 필자도 기존 분석과 논평을 통해 충분히 객관적인 설명과 다소 주관적인 의견을 공유했으므로 말을 아끼겠지만, 개인적으로는 일부 핵심개발자와 같은 마음으로, 감사가 잘 진행되고 이스탄불 HF 제안서 접수 확정기한(5월 17일)이 빨리 오기를 바랄뿐이다.
- ProgPoW도 중요하지만 더 중요한 사안들에 대해서 생각해줬으면 하는 바램이 있다. 사실 이더리움 1.x와는 별도로 이더리움2.0으로 대변되는 세레너티에 대한 움직임도 활발하다. 세레너티에 대한 세부내용은 여기서 논의하지 않겠지만, 그 의미에 대해서 언급하자면, 필자생각에, 이더리움의 마스터 플랜의 마지막 단계인 세레너티는 탈중앙화 범용 플랫폼으로서의 가능성을 제대로 심판받는 과정일거라고 본다.
- 작년과 달리, JP모건, IBM 등과 같은 거대금융사들이 금융분야에서의 플랫폼을 출시하려고 하고있고, Binance, Bakkt 등과 같은 거래 플랫폼도 단순 거래를 위한 곳이 아닌 독자체인을 구축하여 지갑, 결제, 유명파트너사와 협력 등을 모색하고 있으며, 코스모스, 폴카닷 등은 겉으로는 이더리움과 경쟁하지 않는다고는 하지만 IBC(블록체인을 잇는 것)로 연결되어 보다 업그레이드된 이더리움 버전이 나올 가능성도 있다.
- 필자의 너무 앞선 걱정이라고 할수도 있지만 최근 드는 생각은 이 블록체인 및 암호화폐영역에서의 시간이 가속도가 붙는 느낌이다. 따라서, 기존 공룡기업들이 블록체인에 진입해서, 이더리움같은 '원주민'을 몰아낼지 오히려 침입에 실패할지가 주요 관점 포인트다. 여태까지는 커뮤니티, 기술개발 등 집안사정만 잘 챙기면 문제없었지만, 앞으로는 거대공룡과의 경쟁, 정치적 해석 및 다툼 등 집밖사정까지 챙겨야 할것이므로, 그때까지 많은 지지와 비판을 바라며 필자의 글이 그 관심에 조금이라도 도움이 되기를 바라는 바이다.
법적 고지 : 본 게시글은, 투자를 위한 정보제공을 목적으로 작성되었기에 투자결정은 신중을 기하여 주시기 바라며, 참고자료를 토대로 본인 판단하에 내용을 추가, 편집 등 작성되었기에 본인의 허락없이 복사, 배포, 편집 등을 할 수 없습니다.
<References>
1) https://ethereum-magicians.org/t/forming-a-ring-eth-v64-wire-protocol-ring/2857/2
2) https://steemit.com/noco/@jkhkkk/4-p2p
3) https://okky.kr/article/467631
4) https://brunch.co.kr/@nujabes403/13
5) https://lyb1837.tistory.com/41
2) https://steemit.com/noco/@jkhkkk/4-p2p
3) https://okky.kr/article/467631
4) https://brunch.co.kr/@nujabes403/13
5) https://lyb1837.tistory.com/41
