<제55차 이더리움 개발자 회의 안건>
- 관련 링크 : https://github.com/ethereum/pm/issues/77
□ 로드맵
ㅇ 콘스탄티노플 - Ropsten HF 상황- 별다른 특이사항 없음
ㅇ CREATE2 부작용에 대한 안내
- 최근 연기된다는 기사때문에 불안감이 퍼지고 있지만, 해당 버그때문에 연기되지 않을것이다.
- 해당 개선안(CREATE2관련)을 제거하는 것은 쉽지만 그럴 이유가 딱히 없다. 그리고 CREATE2는 앞으로도 필요한 기능이다.
- (회의 말미에) CREATE2이슈 덕분에, 사람들이 그것이 어떻게 작동하는지 이해하는 계기가 생겼다는게 중요하다.(Vitalik)
ㅇ ProgPoW audit(감사)
- ProgPoW 감사 중에 파악된 정보를 이용하여 이익을 취할수도 있기에 누가 감사를 해야할지 정하기가 쉽지 않다.
ㅇ EIP1355"Ethash 1a" 폐기
- ProgPoW가 현재 논의되고 있기에 더이상 필요하지 않기에 폐기해도 된다.
※ Ethash 1a는 Ethash알고리듬에 최소한의 변경을 통해 ASIC기반 채굴을 방해/지연시킴. 이를 통해, 주어진 순서대로 작동되도록 설계된 ASIC에 대해, 특정해시함수(fnv1a)가 그 순서를 변경하여 ASIC을 비활성화시킨다(덜중앙화). 또한, 변경을 최소화하여 혹시 있을 추가 업데이트에 대한 리스크를 줄이고 기존GPU성능에 영향을 끼치지 않는다(보안성유지).
.
ㅇ 이스탄불 HF 로드맵
x 5월 17일로 시한 제안 : 콘스탄티노플HF가 계속 연기되어서, 타임라인 재정립을 위해 나름대로 시한을 정해봤다. 이대로 진행해도 된다(그런데 아직 이스탄불 범위 등 실체가 없는데 무엇을 위한 시한을 제안하는지 잘 모르겠음)
x EIP1418 State Rent : 관련 개발자가 오프라인이라 다음을 기약함.
※ 공용유틸리티인 이더리움에 있어, 스토리지 장기간 사용료를 저렴하게 책정하고자 하며, 이때 책정산식은 'Byte(용량) x time(시간)'.
x HF 이름짓기 도전 : 딱히 생각나는게 없어서, 도전 실패!
ㅇ 전망 : PoW체인(Serenity)에서의 PoS 확정성 이행
- 비콘체인, 확정성 이행의 접근방식 등에 대한 논의(어려운 내용에 주요 이슈가 아니라서 쓰다지우다 결국 한줄로 정리함;;)
□ 업무별 업데이트
ㅇ 이더리움 1.x 스탠포드 미팅 개요 : 다루지 않음ㅇ State Rent : 관련 개발자가 오프라인이라 다음을 기약함.
<부연설명>
- 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 : 다루지 않음
< 부연 설명 >
- Pruning(프루닝)은 소위 가지치기를 통하여 저장공간을 줄여주는 방식이다. 이더리움에서 스테이트는 항상 최신상태만 유지하지 않고 과거 일정기간의 히스토리까지 보관한다. 그 이유는, 노드간 합의가 되어 한 블록이 생성되어도 아직 확정되어 있지 않는 경우, 분기(bifurcated)될 가능성이 있고 분기 발생시 스테이트를 되돌려야(rollback)해야 될수도 있기 때문에, 최종 확정되기전까지는 히스토리가 있어야한다. 이후 일정시간이 지나면 프루닝을 통해 히스토리가 삭제되고 저장공간을 줄여준다.
- Sync(동기화)는 말 그래도 어떤 대상에 맞추는 것을 의미하는데, 블록체인의 노드로 동작하기 위해서 블록데이터를 다운로드하여 싱크를 해야한다.
ㅇ Simulation : 다양한 블록체인 모델 시뮬레이션
- 다루지 않음
ㅇ 향후 오프라인 미팅에 대하여 : 긍정적으로 생각함
□ 테스팅 업데이트 : 특이사항 없음
□ 클라이언트 업데이트 : 클라이언트별 각 담당자가 그간 업데이트 내용 및 당부사항 안내.
ㅇ Geth
ㅇ Parity Ethereum
ㅇ Aleth/eth
ㅇ Trinity/PyEVM
ㅇ EthereumJS
ㅇ EthereumJ/Harmony
ㅇ Pantheon
ㅇ Turbo Geth
ㅇ Nimbus
ㅇ Mana/Exthereum
ㅇ Mantis
□ 리서치 업데이트
ㅇ Ethereum2.0(Serenity)을 단계(Phase)별로 그간 분석과 생각한 바를 언급(Vitalik)- 특히 Phase0에 대한 언급이 가장 많았는데 현재 가장 중점을 두고 있는 단계이다.
- 또한, 각 Phase별로 순차적으로 진행하며, 복수의 Phase를 동시에(병렬로) 진행하는 것을 지양한다.
- 아울러 어떤 Phase가 2021년에 완료 등 선동(trolling)하지 않도록 향후 진행상황 및 일정에 대한 언급을 조심스럽게 하겠다.
※ Ethereum2.0에 대한 자세한 스펙 및 진행을 보려면 여기를 클릭
□ 개인 논평 "최근이슈와 이더리움 정신"
*논평에 앞서, 이번 회의는 1시간만에 끝났으며, 핫이슈인 'ProgPoW에 대한 비중'이 적었다. 그 덕분에 다른 다양한 이슈들에 대한 논의가 가능했고, 그 때문에 커뮤니티가 원하는 내용을 자세히 알지 못했다. 어쨋든 적은 비중에 따라, 이번 논평에는 ProgPoW를 다루지 않겠다.
- 다가오는 콘스탄티노플 HF가 또다시 연기될수도 있다는 며칠전 분석이 있었으며, 그 이유는 CREATE2(보안을 해칠 버그)때문이다.
- CREATE는 스마트컨트렉트(이하 '컨트렉트)의 계정(account)을 생성하는 명령어(opcode)로, 생성될 계정을 메모리 번지, wei 등을 설정하며 우선 임의생성한다. 이게 필요한 이유는, 가령 토큰런칭시 미리 설정된 전략 외에 수요/상황에 따라 다양한 토큰 전략을 추가할수 있는 유동성이 필요하였고, CREATE 덕분에 대략적인 사안만 정하고, 새 컨트렉트가 생성 및 배포되면 그에 따른 주소를 만들수 있다.
- 하지만, 컨트렉트가 생성 및 배포되어야만 주소를 알수 있는 CREATE와 달리, 컨트렉트가 배포 이전이라도 해당 컨트렉트에 따른 주소를 미리 파악할수 있는 CREATE2가 제안되었고, 이 특성이 또다른 콘스탄티노플 연기의 이유가 되어버렸다.
- 시나리오를 쓰자면, 컨트렉트를 제거하는 방식인 self-destruct(자체파괴)을 통해 (가령 온체인상) 컨트렉트를 제거한 후에라도, CREATE2를 써서 (오프체인 상) 주소를 만드는데, CREATE2특성상 언제든 그 주소를 변경할수 있고, 또 미리 그 주소를 파악할수 있다.
이 특성들을 악용하면, (온체인상) 제거한 컨트렉트에 따른 주소와 동일한 주소를 이론상 얻을수 있고, 이 경우 자금탈취 또는 이중 컨트렉트가 일어날수도 있다는 거다. 한마디로, (한 체인 상)컨트렉트를 제거했음에도 CREATE2의 사전주소파악 및 주소변경 특성때문에 (다른체인상으로부터) 보안의 틈이 발생한다는 의미다.
=> 회의에서 언급된대로 이 버그(기능)때문에 콘트탄티노플HF가 또 연기되지는 않을것 같고, 다만 이에 대한 분석 및 부작용 방지는 반드시 짚고 넘어가야 할것이다.
ㅇ '연기(delay) 트라우마'에 빠진 이더리움??
- 비단 콘스탄티노플 HF 연기뿐만아니라 이더리움의 더딘 일정덕분에 얼핏보기에 이더리움이 소위 '연기 트라우마'에 빠졌다고 볼 수 있다. 과연 무엇이 문제인가??
- 본인은 투자자로서 생긴 답답한 마음을, 분석가로서 이더리움 진행상황을 추적하여 해소하기로 했고, 그결과를 요약하면 아무도 가지 않는 길로 가려는 '프론티어 정신(frontier spirit)'과 세부사안 간 최적화, 안정성 등에 집요한 '장인정신(craftsmanship)'때문이다.
- 먼저 프론티어 정신의 경우, 이더리움 개발자 특히 비탈릭은 가끔은 과하다 싶을정도로 새로운 것을 쫓는다. 최근 지미송이 비탈릭을 Neo maniac(새것을 추구하는 자)이라고 비판한 걸 예로 들자면, 비트코인 주소 포맷은 base58*을 써서 코인 송금용 주소가 유효한지 확인이 되어 안전하지만, 이더리움 주소 포맷은 그런 체크섬(checksum)이 없기때문에 한 글자라도 틀리면 전송 코인은 사라진다.
*base58 : Binary data를 text로 변경해주는 encoding 기법.
- 따라서, 새로운 것을 쫓는 덕분에 이더리움이 나왔고 다양한 기능과 서비스들이 제공되었지만, 또 그만큼 파생되는 문제점들이 많이 발생되었다. 같은 이유로, 참신한 EIP(이더리움 개선안)들이 나왔지만 그들의 충돌이 콘스탄티노플HF의 발목을 잡은것이다.
- 장인정신의 경우, 캐스퍼(이더리움의 PoS전환 프로젝트)의 느긋해보이는 진행속도가 대표적인 예다.
- 계획대로라면 이미 캐스퍼가 개시되어야 맞지만 마음에 들지 않는 도자기는 과감히 깨부수는 도자기 장인처럼, 이더리움 개발자 특히 비탈릭은 2014~2015년 간 추진한 캐스퍼방식(Casper by betting)을 위험한 방식이라 하여 덮어놓고, 보다 개선된 캐스퍼(Casper FFG)추진을 2016년부터 시작한다.
=> 물론 위의 2가지 요인이 이더리움의 느슨한 진행의 원인이라는 건 사견이다. 중요한 것은, 계속되는 연기의 본질이라고 생각한다. 불현듯 찾아온 2016~2017년 찾아온 이더리움의 급등은 많은 사람들에게 이더리움이 진정 혁신의 아이콘이라고 각인시켰겠지만, 거품이 빠진 2018년부터 이더리움은, 혁신은 온데간데 없는 평범(mediocre) 그 자체로 전락했다. 과연, 과거의 잘나가던 이더리움이 본 모습이었을까, 아니면 거품이 빠지며 드러난 평범의 극치가 본 모습일까. 솔직히 난 평범한 후자의 모습이 이더리움의 본모습에 가깝다고 생각한다. 다만, 평범이라고 해도 본인이 보기엔 어떻게 살아가야하는지를 평범 그 이상으로 고민하고 있다고 보기에, 그 판단에 따라 때론 지치고 힘들지만 그럼에도 '불안한 희망'을 걸어본다.
법적 고지 : 본 게시글은, 투자를 위한 정보제공을 목적으로 작성되었기에 투자결정은 신중을 기하여 주시기 바라며, 참고자료를 토대로 본인 판단하에 내용을 추가, 편집 등 작성되었기에 본인의 허락없이 복사, 배포, 편집 등을 할 수 없습니다.
