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

'제54차 이더리움 개발자 회의(01 Feb 2019)' 결과 총정리 및 개인논평을 작성해봤습니다. 

 

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

 

 

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

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

 

 

 

□ 로드맵

  ㅇ 콘스탄티노플 - Ropsten fork?

    - Geth, ParityEthereum 등 클라이언트별 Robsten Fork 시점과 내용 간단히 언급하였다.

 

  ㅇ Istanbul Hardfork Roadmap

    - 지금도 진행중인게 많다며 다루지 않았다.

 

  ㅇ Outlook: PoS finality gadget on PoW chain (Serenity)

    - 이 분야에 대해 잘 하는 비탈릭이 현재 스탠포드 컨퍼런스 참석 중이기 때문에 다음을 기약하였다.

 

  ㅇ ProgPoW audit?

    - (개요) 우리는 ProgPoW에 대해서 제대로 잘 모르기 때문에 이 새로운것에 대해 제대로 살펴볼 필요가 있다.

    - (누가) 우선 '누가' ProgPow 감사도입을 결정할까에 대한 논의가 시작되었으며, 세상(커뮤니티)에 물어보자부터, 다른 그룹에 물어보자 등 다양한 의견이 나왔고, 우리(개발자)가 그냥 결정하자며 그게 우리가 할일이다라는 의견도 있었다.

    - (어떻게) 또한 '어떻게' ProgPow감사도입을 결정할까에 대한 논의 역시 있었으며, ProgPow에 대한 감사를 진행하자는 제안이 있어 이에 대한 세부논의 이어졌다. 감사를 최소한 2개 그룹에서 진행하자부터, 커뮤니티 여론을 모으기 위해서 채굴시 '지지(Support)' 또는 '반대(Not support)'같은 시그널 메세지를 자유롭게 입력하게하여 채굴현장의 목소리를 취합해보자는 의견도 있었다. 참고로 감사는 최소한 2주부터 4주의 기간이 필요하다는 제안이 있었다.

    - (언제) 그리고 '언제' ProgPow감사도입을 결정할까에 대한 논의도 있었으며, 이스탄불 HF 이전이냐 이후냐에 대한 말도 있었지만 이스탄불HF조차 정해지지 않아 큰 의미가 없으며, 일부 개발자는 3월이나 4월초가 될것 같다고 했으나 특정 시점을 정하지는 못하다.

    - (결론) 결론적으로 감사 개시에 대한 합의는 모아졌고, 감사 중 문제가 생기면(Red flags) 실행을 멈추지만, 어떠한 문제도 생기지 않고 커뮤니티의 여론도 긍정적이면 ProgPow도입이 가능하다. 

 

 

□ 과업별 업데이트

  ㅇ Ethereum 1.x Stanford Meetings Overview

    - Ethereum 1.x 개념이 나온 배경과 취지를 설명하였는데, 요약하자면 Ethereum 2.0(Serenity)가 오기전의 시간을 헛되이 보내지 않기위한 프레임을 만들어, 그 기간안에 여러 팀별로 의미있는 개선안 제안과 그에 대한 개발 진행 등 일종의 프레임워크다.

 

  ㅇ State Rent

    - State Rent에 대해 간단히 설명하고 지나갔다.

 

   < 부연설명 >

    - State(스테이트)란 이더리움 노드에 저장된 eth, code, contract 등을 모아놓은 데이터로, 트랜잭션의 유효성 검증 및 결과 확정 역할을 한다. 따라서, 스테이트 용량이 클수록 검증시간이 길어진다. 참고로 19.1.29일 현재 이더리움 스테이트 용량은 127GB로, 다른 암호화폐 그것과 비교할때 큰 편에 속한다.

    - 이더리움 스테이트는 전년동기 대비 약 3배정도 용량증가를 보였으며, 시간이 흘러 언젠가는 모든 데이터를 저장하는데 부담이 될수있다. 이에 비탈릭은 2018년 '네트워크 데이터 저장 임대'를 제안한다.

    - 우리가 익히 알고 있는 이더 전송 등 이더리움 네트워크를 이용할때 지불하는 일종의 '전송 수수료'와 달리, 비탈릭이 제안한 것은 네트워크에 데이터를 저장할때 지불하는 일종의 '저장 수수료'다.

    - 현재 개발중인 샤딩(방대한 데이터를 분리, 저장하여 따로 처리하는 방식)의 도입은 수 년이상 걸리고, 도입된다해도 근본적인 해결방안이 되지 않기때문에, 저장데이터 양과 기간에 비례하여 수수료를 내는 것을 제안한다.

    - 더불어, 전체 데이터 용량조절을 위해서, 용량한도에 다다를수록 수수료가 높아져 신규저장데이터 감소를 유도하는 방안을 계획중이다.

    - 다만, 데이터를 저장하기전에 저장기간을미리 예측해서 설정해야하는 문제, 수수료에 대한 사용자의 부담감 등이 걸림돌이다.

 

  ㅇ eWasm

    - 일부 개발자의 eWasm에 대한 경험담, 소감, 생각 등이 언급되었다(Blah~ blah~).

 

   < 부연설명 >

    - 향후 Serenity단계에서 EVM을 웹 어셈블리 기반인 eWasm으로 변경할 계획이다.

    - 현재 EVM은 너무 복잡하고 성능은 떨어지며, 지원되는 프로그래밍 언어와 개발 툴이 제한적힌 반면, eWasm은 이진법을 사용가능하며, 효율적으로 각종 프로그래밍 언어와 개발 툴 등이 지원가능하다.

    - eWasm은 EVM에 비해서 솔리디티 외 다양한 프로그래밍 언어로 코딩이 가능(범용성)하고, 빠른 속도로 트랙잭션 처리가 가능(속도향상)하며, 웹어셈블리 개발 커뮤니티의 지원을 그대로 받을수 있다(인력풀 증가).

    - Serenity의 과정까지 단기간 개선사항으로 EVM와 하위 호환가능한 eWasm버전(EVM 1.5)을 메인넷에 채택하고 Serenity에서 비컨체인 도입이후 2단계(Phase 2)에서 제대로 된 eWasm(EVM 2.0)이 사용될 예정이다.

 

  ㅇ Pruning/Sync : 다루지 않음

 

   < 부연설명 >

    - Pruning(프루닝)은 소위 가지치기를 통하여 저장공간을 줄여주는 방식이다.

    - 이더리움에서 스테이트는 항상 최신상태만 유지하지 않고 과거 일정기간의 히스토리까지 유지보관하는데, 그 이유는 노드간 합의가 되어 한 블록이 생성된후라도 아직 확정되어 있지 않는 경우, 분기(bifurcated)될 가능성이 있어서 스테이트를 되돌려야(rollback) 될수도 있기때문에, 최종 확정되기전까지는 히스토리가 유지되어야한다. 이후 일정시간이 지나면 프루닝을 통해 히스토리가 삭제되며, 따라서 저장공간을 줄일수 있다.

    - Sync(동기화)는 말 그대로 어떤 대상에 맞추는 것을 의미하는데, 블록체인의 노드로 동작하기 위해서 블록데이터를 다운로드하여 싱크를 해야한다.

 

  ㅇ Simulation : 다양한 시뮬레이션에 대한 과정, 결과에 대해 언급함

 

□ 테스팅 업데이트 : 해당없음

 

□ 클라이언트 업데이트 : 주로 Constantinople fix를 반영했다고 언급함.

  ㅇ Geth

  ㅇ Parity Ethereum

  ㅇ Aleth/eth

  ㅇ Trinity/PyEVM

  ㅇ EthereumJS

  ㅇ EthereumJ/Harmony

  ㅇ Pantheon

  ㅇ Turbo Geth

  ㅇ Nimbus

  ㅇ Mana/Exthereum

 

□ 리서치 업데이트 : 특이사항 없음

 

 

<개인 논평> 격화된 ProgPow이슈

  ㅇ ProgPow을 위한 알쓸신잡

    - 제 글이 어렵다는 사람들이 있어서 잠시 이해를 돕기 위해 부연설명을 해보겠다. 

    - 우선 ProgPow는 ASIC채굴의 상대적 높은 효율성을 반감시키는 PoW변형알고리듬으로, AMD, NVIDIA 등이 제조하는 그래픽 카드에서 테스트되고 적용되며, 따라서 카드제조업체 및 산업에 적지않은 영향을 줄수 있고,  동시에 이더리움 전체 해시레이트와 연관이 있으며, 채굴에도 영향을 끼친다.

    - 현재 Ethash의 경우, 범용 GPU가 메모리 활용시 약60%정도만 활용해서 비효율적인데 반해 FPGA나 ASIC은 이런 비효율적인 메모리 활용을 임의설계하여 메모리 효율성을 높이기 때문에, 채굴 관점으로 보면 그 향상된 효율성이 곧 향상된 채산성으로 이어지게 되는 것이다.

    - 이에 ProgPow의 필요성이 대두되었고, ASIC의 향상된 효율성을 반감시키위하여, Ethash를 사용하면서도 상용GPU자원을 최대한 활용되도록 수정하는 것이 ProgPow의 디자인이다.

    - 실제로 AMD, NVIDIA 모델을 통한 테스트를 진행했는데, 해당 모델들의 계산능력과, 메모리 대역폭의 효율성을 높일수 있었다.

    - 다만 Ethash 대비 ProgPow가 해시당 메모리 접근성이 두배에 달하기 때문에 해시레이트가 절반정도로 낮아지는 현상이 벌어지게 된다.

    - 결론적으로, ProgPow이슈에 대한 관점은 ASIC를 얼마나 때려잡아야 하는가보다는 기본GPU자원을 얼마나 잘 활용해서 ASIC효율성을 감쇄할수 있느냐로 봐야하는 문제에 가까우며, 이는 결국 이더리움 해시레이트에 영향을 끼치기 때문에 생각보다 복잡한 문제다.

 

< 그래픽카드별 Ethash와 ProgPow에서의 해시레이트와 메모리 대역폭 활용도(https://medium.com/@ifdefelse) >

 

  ㅇ ProgPow을 위한 주사위는 던져졌다

    - 지난 작성글인 '미리보는 제54차 이더리움 개발자 회의'작성시점과 실제회의의 안건들이 차이가 있었고, 그 차이는 'ProgPow audit(감사)' 안건추가였으며, 덕분에 ProgPow에 대한 세부논의가 이어졌다.

    - 여태껏 지지부진했던 ProgPow 감사 및도입에 대해서 90분간의 회의 중 약 60분동안 다룰정도로 심도있게 논의되었고, 아직 세부사항에 대해 확정은 되지 않았지만 상당히 의미있는 시간이었다고 감히 평가하고 싶다.

    - 작년부터 시작된 일부 개발자와 커뮤니티로부터 제기된 ProgPow이슈가 현재 논쟁의 마침표를 찍고자 하는것에 대하여, 누군가는 '이제서야 정신차리나'할수도 있고 다른 누군가는 '이제라도 조치를 해서 다행이다'라고 할수있다.

    - 가치판단의 문제이기에 어느쪽이 옳다고 말할수는 없지만, 중요한것은 커뮤니티 의견을 존중하는 태도와 이더리움 전체 프로젝트의 균형적 발전을 하려는 태도라고 생각한다.

    - 따라서, 이더리움 측이 그런 좋은 태도를 보이는지는 앞으로 ProgPow에 대한 그들의 대응을 보면 알수있을것이고, 그 판단에 따라 이더리움에 대한 지지 등 입장을 유지 또는 변경하면 될 일이라고 본다.

 

 

*'좋아요'와 '댓글' 환영합니다~^^