블록체인허브 (blockchainhub.kr) - 블록체인 포털
홈 > 포럼 > 코인논객 오공
포럼포럼   코인논객 오공 암호화폐 소수의견서(Minority Report)

[Ethereum] '제57차 이더리움 개발자 회의' 분석 및 개인 논평 v1.0

코인논객오공 177 1,073 2019.03.16 02:01

안녕하세요, 코인논객 오공입니다.

격주로 진행되는 이더리움 개발자 회의가 오늘(57차) 있었으며, 그 내용과 분석, 논평을 공유합니다.

많이 어렵겠지만 아는 내용이라도 관심있게 가지면 도움이 될까 생각됩니다.

솔직히 저에게도 정말 어려운 내용이고 이 개발자 회의를 생방송으로 들으면서, 

그와 동시에 정리와 분석, 논평을 적어 공개적인 곳에 공유하는 것이 개인적으로 큰 부담입니다.

하지만 저의 부담을 발판으로 최소한 이더리움 투자자나 분석가에게 큰 도움이 되길 바랍니다. 

*편의상 '~이다/하다'체로 작성하였음을 미리 양해바랍니다 


<제57차 이더리움 개발자 회의 안건>

- 관련 링크 : https://github.com/ethereum/pm/issues/83


57%25EC%25B0%25A8%2B%25EC%259D%25B4%25EB%258D%2594%25EB%25A6%25AC%25EC%259B%2580%2B%25EA%25B0%259C%25EB%25B0%259C%25EC%259E%2590%2B%25ED%259A%258C%25EC%259D%2598.JPG



□ 로드맵

  ㅇ 이스탄불 하드포크(이하 '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이며, 그래프로 표현하면 다음과 같다.

%25ED%2583%2580%25EC%259B%2590%25EA%25B3%25A1%25EC%2584%25A0.png

< 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(블록체인을 잇는 것)로 연결되어 보다 업그레이드된 이더리움 버전이 나올 가능성도 있다.

    - 필자의 너무 앞선 걱정이라고 할수도 있지만 최근 드는 생각은 이 블록체인 및 암호화폐영역에서의 시간이 가속도가 붙는 느낌이다. 따라서, 기존 공룡기업들이 블록체인에 진입해서, 이더리움같은 '원주민'을 몰아낼지 오히려 침입에 실패할지가 주요 관점 포인트다. 여태까지는 커뮤니티, 기술개발 등 집안사정만 잘 챙기면 문제없었지만, 앞으로는 거대공룡과의 경쟁, 정치적 해석 및 다툼 등 집밖사정까지 챙겨야 할것이므로, 그때까지 많은 지지와 비판을 바라며 필자의 글이 그 관심에 조금이라도 도움이 되기를 바라는 바이다. 


* 추천과 댓글 등 피드백은 저에게 큰 힘이 됩니다.  

추천&비추천 정책안내

신고
  • 카카오톡으로 보내기
  • 페이스북으로 보내기
  • 트위터로 보내기
  • 구글플러스로 보내기
  • 카카오스토리로 보내기
  • 네이버밴드로 보내기
  • 네이버로 보내기
  • 텀블러로 보내기
  • 핀터레스트로 보내기

Comments

코인논객오공 19-03-17 22:25 0   0
안락한나검님 어려운 글을 공유해서 괜시리 죄송한 마음입니다. 포스팅에 감안하겠습니다. 늘 고맙습니다~
바른부자 19-03-18 09:36 1   0
좋은정보 감사합니다~ 좋은하루 보내세요~
깡창 19-03-18 20:21 1   0
감사합니다

축하합니다! 행운의 3 HUB가 적립되었습니다 ^.^

코인논객오공 19-03-20 23:25 0   0
양봉돼지님 포럼 잘 보고 있습니다. 좋은 자료 공유 고맙습니다
코알라 19-03-21 08:08 1   0
잘봤습니다~ 몇십번 더 읽어봐야겠네요~ㅎ.ㅎ 감사합니다~^^
코인논객오공 19-03-28 11:50 0   0
돈창고님 안목이 고급져서 그렇게 보이는겁니다. 좋게봐주셔서 고맙습니다~

[오공]레이븐 개발자 회의 및 논평(May 11, 2019) v1.0 151

안녕하세요, 코인논객오공입니다.개인적으로 특정 암호화폐 또는 프로젝트에 대한 글을 작성하는 것을 지양하지만 제가 관심있는 것에 대해서는 예외입니다.비트코인, 이더리움, 코스모스(아톰) 등이 바로 그 예외사항이며, 작년에 처음 알았지만 올해 들어 관심을 가진 '레이븐(Raven)' 프로젝트도 그 중 하나가...
1,081 | 153 | 2019.05.19

[오공]역대 주요 코인 거래소의 변천사(2부작) 2부 v1.0 175

안녕하세요, 코인논객오공입니다.이전 1부글에 이어서 '역대 주요 거래소의 변천사' 2부를 소개합니다.소개할 거래소를 더 추가할까 하다가 일단은 지난 3월에 작성한대로 공유해드립니다.*편의상 '~이다/하다'체로 작성하였음을 미리 양해바랍니다. ㅇ 코인베이스(Coinbase) - 2012년 6월 브라이언 암...
578 | 91 | 2019.05.17

[오공]역대 주요 코인 거래소의 변천사(2부작) 1부 v1.0 183

안녕하세요, 코인논객오공입니다.현재 '익명성' 관련 글을 기고중인데, 잠시 쉬어가는 차원에서 여러분들이 좋아할만한 글을 소개합니다.우리가 트레이딩을 할때 흔히 사용하는 거래소에 대한 내용으로 정확히는 '역대 주요 거래소의 변천사'입니다.이해하기 어렵지 않도록 최대한 기술적 용어는 배제했으며, 지난 3월 ...
793 | 83 | 2019.05.14

[오공]'제61차 이더리움 개발자 회의' 분석 및 개인 논평 v1.0 215

안녕하세요, 코인논객오공입니다.격주로 진행되는 이더리움 개발자 회의(61차)가 있었으며, 그 내용과 분석, 논평을 공유합니다.항상 이더 개발자 회의 글을 올리면서'이걸 다 이해하시는 분이 얼마나 될까'주저하지만, 단 한분이라도 이해하시길 바랄뿐입니다.*편의상 '~이다/하다'체로 작성하였음을 미리 양해바랍...
1,238 | 112 | 2019.05.11

[Privacy]익명성 코인의 아이콘, "모네로(XMR)" 131

안녕하세요, 코인논객오공입니다.현재 익명성 관련 글을 기고중인데, 너무 이론만 주구장창 서술한점이 어렵게 느껴질수도 있다는 생각을 했습니다.따라서, 이번글에서는 관련 특정코인을 소개하면서 이론도 같이 설명하는 방식을 활용해봤습니다.그럼에도 어렵게 느껴지신다면 양해말씀드리며, 궁금한점은 댓글, 쪽지, 텔레...
641 | 69 | 2019.05.09

[Privacy]'영지식증명'의 진화(zk-SNARK vs. zk-STARK) v1.0 181

안녕하세요, 코인논객오공입니다.지난번 '영지식증명 개론'​ 글을 많이 어려워 하셔서 고민이 많습니다. 왜냐면 이번 글도 쉽지 않기 때문이죠.그래서 '아예 올리지 말까' 진지하게 생각했지만, 혹시 도움될 분이 단 1명이라도 있으리라 기대하며 지속 공유하기로 했습니다.정말 모르는 수준이면 관련 배경지식을 구...
746 | 96 | 2019.05.06

[Privacy]‘영지식증명’ 개론(feat. zk-SNARKs) v1.1 153

안녕하세요, 코인논객오공입니다.포럼초기부터 공유한 '합의프로토콜' 시리즈에 이어 이번엔 '개인정보보호와 익명성' 시리즈를 공유합니다.합의프로토콜보다 더 생소하고 더 어려울수도 있지만, 그 중요성은 결코 떨어지지 않다고 생각합니다.따라서, 블록체인과 암호화폐를 공부하고자 하는 분들은 잘 숙지하여 주시기 바...
765 | 76 | 2019.05.03

[Poem] 코인 헤는 밤(원작: 별 헤는 밤) // Coin Starry Night 165

안녕하세요, 코인논객시인 오공입니다.이번에는 딱딱한 분석글 대신에 저번에 공유한 자작시 '코인판에서의 고해'에 이어서제가 좋아하는 윤동주 시 '별헤는 밤'을 패러디한 시를 공유하오니 가벼운 마음으로 봐주시기바랍니다.< Bitcoin Starry Night// 비트코인이 빛나는 밤>"코인 헤는 ...
796 | 85 | 2019.04.30

[Ethereum] '제60차 이더리움 개발자 회의' 분석 및 개인 논평 v1.0 197

안녕하세요, 코인논객오공입니다.격주로 진행되는 이더리움 개발자 회의(60차)가 있었으며, 그 내용과 분석, 논평을 공유합니다.*편의상 '~이다/하다'체로 작성하였음을 미리 양해바랍니다.<제60차 이더리움 개발자 회의 안건>- 관련 링크 :https://github.com/ethereum/pm/...
960 | 99 | 2019.04.27

[Consensus] 이오스학 개론(feat.이더리움) -개론시리즈(3) v1.2 149

안녕하세요, 코인논객오공입니다.이전글에서 포럼초기부터 '합의프로토콜'이라는 큰 테마로 시리즈를 포스팅 했는데요,이번글은 그에 대한 "번외편"으로 PoS계열 중 하나인 'DPoS'의 대표주자, 이오스(EOS)에 대하여 작성해봤습니다.*편의상 '~이다/하다'체로 작성하였음을 미리 양해바랍니다.□ 이오스의 개...
846 | 81 | 2019.04.25

[총정리] '합의프로토콜' 시리즈를 마치면서 v1.1 147

안녕하세요, 코인논객오공입니다.이번 글은 그간의 메인 테마였던 '합의프로토콜(Consensus Protocol)' 시리즈를 마친 소회를 공유합니다.우선 제 글이 어려울수도 있지만 '가즈아만 외치며 틀리면 말고식의 가벼운 분석글'과 '너무 기술적이고 딱딱한 내용들이 난무하는 논문수준의 어려운 글'의 중간 ...
768 | 77 | 2019.04.22

[Consensus] 마이닝2.0시대가 오고있다(2부작) 2부 "마이닝2.0여파와 블록체인 이데올로기" v1.6 117

안녕하세요, 코인논객오공입니다.지난번 1부 "마이닝1.0과 마이닝2.0"에 이어, 2부 "마이닝2.0의 여파와 블록체인 이데올로기"를 공유합니다.약 2주전에 써놓고는 업로드하는 순간까지 계속 수정하게 되네요.. 부족하지만 잘 봐주시기 바랍니다.*편의상 '~이다/하다'체로 작성하였음을 미리 양해바랍니다.□...
803 | 62 | 2019.04.19

[Consensus] 마이닝2.0시대가 오고있다(2부작) 1부 "마이닝1.0과 마이닝2.0" v1.6 183

안녕하세요, 코인논객오공입니다.포럼 초기 글부터 꾸준히 다뤘던 합의프로토콜의 '총론'격인 글을 비로소 공유합니다.초안은 이번 글의 5배가 넘는 심오한 글이어서, 싹다 갈어엎고 정제해서 다시 썼지만그래도 길어서 2부작으로 나눴습니다(1부 : 마이닝1.0과 2.0 // 2부 : 마이닝2.0의 여파 및 개인 ...
1,054 | 105 | 2019.04.16

[Ethereum] '제59차 이더리움 개발자 회의' 분석 및 개인 논평 v1.0 138

안녕하세요, 코인논객오공입니다.격주로 진행되는 이더리움 개발자 회의(58차)가 있었으며, 그 내용과 분석, 논평을 공유합니다.*편의상 '~이다/하다'체로 작성하였음을 미리 양해바랍니다.<제59차 이더리움 개발자 회의 안건> - 관련 링크 : https://github.com/ethereum/p...
921 | 79 | 2019.04.13

[Poem] 코인판에서의 '고'해 151

안녕하세요, 코인논객오공입니다.블록체인과 암호화폐를 탐구하다 일부 트레이더들을 보던 중, 시상(詩想)이 떠올라 가볍게 자작시 한편 공유합니다.분석과 논평을 하다가 왠 시 냐고 물으신다면 제가 원래 감수성이 풍부하다는 말밖엔 못 할것 같습니다(저 술 안마셨습니다;;).괜시리 부끄럽지만 이 시를 보면서 '블...
752 | 91 | 2019.04.11

[Consensus] 만약에 비트코인이 PoS로 나왔다면 어땠을까 ('만약에' 시리즈1) v1.2 138

안녕하세요, 코인논객오공입니다.본 포럼을 개설한 이후로 PoW와 PoS의 합의프로토콜 위주로 기고하였습니다.이 글은 그동안 이전의 관련 글들에 안내한 내용을 복습할 겸 재미있는 상상을 해보기 위한 글입니다.여러분들도 저의 상상에 동참해주시길 바라며, 또한 제 글 내용이 대부분 어렵지만 앞으로도 같이 분석...
687 | 76 | 2019.04.08

[Technology] 안전성과 생존성, 그리고 동기성(feat. FLP impossibility) v1.3 129

안녕하세요, 코인논객오공입니다.중간중간 다른 소재의 글로 인해, 옆으로 새긴 했지만 '합의알고리듬'에 대한 글을 이어가겠습니다.이번 글도 조금 어렵습니다. '보약' 먹는다는 생각으로 봐주신다면, '사탕'같은 흥미로운 글로 추후 꼭 보답하겠습니다.*편의상 '~이다/하다'체로 작성하였음을 미리 양해바랍니다....
861 | 74 | 2019.04.05

[Insight] ICO와 STO에 대한 고찰(feat. tZERO) v1.0 133

안녕하세요, 코인논객오공입니다.제가 현재 트렌트와 관련없는 글들을 포럼에 올리긴 하지만, 늘상 코인시장의 현재 트렌드를 체크하며 개인적으론 메모를 합니다.이 글 역시 ICO를 지나고 STO를 맞이하는 현 트렌트에 맞춘 것이며, 다만 2월초에 작성된 점을 감안하여 읽어주시기 바랍니다.*편의상 '~이다/하다...
770 | 76 | 2019.04.02

[Ethereum] '제58차 이더리움 개발자 회의' 분석 및 개인 논평 v1.0 176

안녕하세요, 코인논객오공입니다.격주로 진행되는 이더리움 개발자 회의(58차)가 있었으며, 그 내용과 분석, 논평을 공유합니다.*편의상 '~이다/하다'체로 작성하였음을 미리 양해바랍니다.<제58차 이더리움 개발자 회의 안건>- 관련 링크 : https://github.com/ethereum/pm...
919 | 90 | 2019.03.30

[Technology] 체크포인트(The firewall for the better network) v1.3 103

안녕하세요 코인논객오공입니다.이번 글은 합의알고리듬 영역으로 다시 돌아와서, PoS에서의 중요한 키워드인 '체크포인트'를 다뤄보도록 하겠습니다.'체크포인트'는 블록체인 네트워크의 확정성과 안전성을 높이기 위한 일종의 방화벽 역할을 하는 메커니즘입니다.참고로 확정성과 안전성에 대해 잘 모르시는 분은 저의 ...
1,138 | 60 | 2019.03.27


추천 최신주간월간

최근글

최근댓글