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

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

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



□ 지난 회의 리뷰 및 추가 논의

  ㅇ EIP-1283(https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1283.md)
    - 지난 주말동안 Gitter를 통해 논의 한 결과, 기존 제안에 추가 섹션을 더했고 따라서 별도의 EIP이름으로 변경되어 다시 제안되어야 할 필요가 있다. 이미 지난 하드포크(Petersburg HF)이후 수 개월간 테스트넷에서 문제없이 실행되었기에 어느정도 검증도 되었다.
    - 다만, 세부 변경사항이 있는만큼 다른 EIP들과의 상호 보완/호환되는지와 그 자체로도 잘 실행되는지가 중요하다.
    - EIP-1706은 EIP-1283과는 완전 다른 별개의 제안으로 보는 의견에는, EIP-1706이 EIP-1283에 치료제같은 역할을 하며 따라서 상호연관이 있다는 반박이 있었다.
    - 기존 콘스탄티노플HF에 적용될뻔한 EIP로, 총 가스 계량기(Net gas metering)를 변경하여 컨트렉트 저장소를 위한 새로운 활용가능성과 대부분의 작동방식이 안 맞을때 발생하는 과도한 가스비 감소에 도움이 된다. 즉, 불필요한 가스비를 줄이는 코딩을 가능케한다.
    - EIP-1706와 관련되어있는 기존 콘스탄티토플HF 적용 후보EIP로, 그때에 비해 큰 변화는 없으며 관련 개발자가 추가되었다. 다만, 이스탄불HF에 적용시 이 두 EIP(1706, 1283)가 결합되어 적용될수도 있으나 아직 합의가 되지 않기 때문에 검토가 필요하지만, EIP-1283은 지난 HF에도 적용될수도 있었던 제안으로, 이미 준비가 되었기에 이스탄불HF적용되었으면 한다. 그전에 EIP-1283팀 간에 합의를 통해 최종 의견을 내세울테니 그때 최종승인할지 다뤘으면 한다.

  ㅇ EIP-2028(https://eips.ethereum.org/EIPS/eip-2028)
    - Calldata(이더리움 상에서 트랜잭션 요청시 전송 데이트가 저장되는 곳)의 가스비를 현행 바이트 당 68에서 줄인다. Calladata비용이 절감되면 잠재적으로 더 큰 블록이 생겨 네트워크 지연이 증가하지만, 수학적 모델링과 경험적 추정에 의해 네트워크 보안이 강해지고 확장성이 증가되는 부수적인 효과가 있을수도 있다.
    - Calldate 영역에서 가스비는 0byte일때 4Gas, 0byte가 아닐때는 68Gas가 소요되지만, 이 제안을 받아들이면 0byte가 아닐때 가스비가 줄어든다(단, 0btye일때는 여전히 4Gas 소요).
    -  이때 일종의 메모리 역할을 하는 Calldata 대역폭(수용능력)이 높아지면 한 블록당 더 많은 데이터를 넣을수 있기때문에 자연스럽게 확장성이 향상되나, Call데이터의 가스비가 줄어들면 1) 잠재적으로 블록크기를 크게 만들어 자연스럽게 데이터 전송에 따른 네트워크 지연을 야기하고 2) 네트워크 공격비용을 낮춰서 보안에 악영향을 끼친다.

 ㅇ EIP-2027(https://eips.ethereum.org/EIPS/eip-2027)
   - 인터넷 컨트렉트규모 계산(스테이트 렌트H)방식이다. 이더리움은 컨트렉트에 채워지거나 비워진 스토리지 슬롯갯수를 계산하는데, 기존의 슬롯갯수가 현재시점으로 계산하지 않기때문에 슬롯갯수의 순수 변화만 효율적으로 추적하는데, 이 개선으로 총 스토리지 슬롯갯수를 추적하게 된다.
    - 10월로 예정된 이스탄불HF일정에 맞게 이 제안의 개발을 추진가능하냐는 질문에, 해당 개발자는 현재 많은 일을 하고 있기때문에 HF일정에 맞추는 것은 결고 쉽지 않다고 말했다.


□ 로드맵(https://en.ethereum.wiki/roadmap/istanbul) 

   <이스탄불 HF 로드맵>
     - 05월 17일(금) : 이스탄불HF EIP 접수 확정기한
     - 07월 19일(금) : 주요 클라이언트 실행 마감기한
     - 07월 중 : 핵심개발자 미팅(예정)
     - 08월 14일(수) 테스트넷에서의 네트워크 업그레이드*(Ropsten, Gorli, 또는 다른 임시 테스트넷)
      * 19.1월 비탈릭이 포크 대신 네트워크 업그레이드라고 부르고, 체인분기가 일어나는 경우만 하드포크라고 부르기를 이더리움 커뮤니티에 제안한 바 있음.
     -10월 16일(수) 메인넷에서의 네트워크 업그레이트(=이스탄불 HF)

    <이스탄불 HF에 포함될 EIP후보 목록> 
     : 아래 EIP들은 이스탄불 여정에 동행할 후보들로, 핵심개발자들의 승인, 실행, 테스트, 감사, 그리고 다른 작업들이 필요하며, 지속 논의될 예정이다. 자세한 설명은 각EIP링크 또는 이더마술사 EIP포럼(여기 클릭)을 참조 요망

     0> EIP-1679(https://eips.ethereum.org/EIPS/eip-1679)
       - 이스탄불 HF 상황체크용 '메타 EIP'로, 여기서 언급할 EIP들중 '선임 EIP'라고 할 수 있다.
       - 이 메타 EIP는 '이스탄불'로 불리우는 이더리움HF에 포함된 수정사안들을 구체화하기 위함이며, 아직 세부적인 내용은 없는 상태이나 추후 이스탄불HF윤곽이 들어나면서 내용이 추가될 예정이다.

     1> EIP615(https://eips.ethereum.org/EIPS/eip-615)
       - EVM을 위한 서브루틴(subroutines) 및 정적 점프(static jumps)다. '서브루틴과 연산기법을 도입하여 성능향상 등 검증의 최적화를 위한 작업'정도라고 보면 된다.
(자세한 설명은 여기글 후반부를 참조)

     2> EIP-663(https://eips.ethereum.org/EIPS/eip-663)
       - 현재 SWAP과 DUP명령어는 스택상 16의 깊이로 한정되어있는데, 이들과 대응되는
SWAPn과 DUPn을 1024개의 아이템의 모든 깊이까지 접근을 허용한다.

     3> EIP-1057(https://eips.ethereum.org/EIPS/eip-1057)
       - ProgPoW는 특정ASIC이 채굴할수 있는 작업유효간격을 좁히기 위해 고안된 PoW알고리듬으로, ASIC의 향상된 효율성을 반감시키위하여, 상용GPU자원을 최대한 활용되도록 수정하는 것이 ProgPow의 디자인이다.

     4> EIP-1108(https://eips.ethereum.org/EIPS/eip-1108)   *임시승인됨(62차 회의)
       - alt_bn128 프리컴파일 가스비 절감제안서다. 값비싼 타원곡선산술 사전컴파일을 재평가하여
개인정보보호와 확장성을 개선하고자 한다.

     5> EIP-1109(https://eips.ethereum.org/EIPS/eip-1109)
       - PRECOMPILEDCALL이라는 특정 opcode를 생성하여, 일반 CALL실행시 어떤 비용없이 프리컴파일된 컨트렉트를 호출하게한다. 이는 프리컴파일된 컨트렉트들을 호출할때 높은 가스 소비를 하게되는 문제를 해결하기 위함이다.

     6> EIP-1283(https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1283.md)
       - 기존 콘스탄티노플HF에 적용될뻔한 EIP로, 총 가스 계량기(Net gas metering)를 변경하여 컨트렉트 저장소를 위한 새로운 활용가능성과 대부분의 작동방식이 안 맞을때 발생하는 과도한 가스비 감소에 도움이 된다. 즉, 불필요한 가스비를 줄이는 코딩을 가능케한다.

     7> EIP-1344(https://eips.ethereum.org/EIPS/eip-1344)
       - 컴파일링시 체인ID를 지정하고 opcode를 추가하면 그 체인ID에 접근하여 서명의 유효성을 검사하며, 이는 다른 체인간 리플레이 어택 등을 방지할수 있다.

     8> EIP-1352(https://eips.ethereum.org/EIPS/eip-1352)
       - 사전컴파일과 시스템컨트렉트가 차지하는 이더리움 주소 범위를 지정하고자 한다.

     9> EIP-1380(https://eips.ethereum.org/EIPS/eip-1380)
       - 자기호출에 대한 가스비 절감으로, 현재 로드된 컨트렌트의 새 인스턴스를 실행시 호출지시에 대한 가스비를 줄이고자 한다.

     10> EIP-1559(https://eips.ethereum.org/EIPS/eip-1559)
       - 현재의 비요율적이고 불필요한 가스비가 드는 방식을 벗어나, 네트워크 수요에 따라 기본 네트워크 요금을 조정하고 비용 효율성을 높이며 가스비지불에 있어 사용자 편의성을 높이는 새로운 방식이다. (자세한 설명은 여기글 후반부를 참조)

     11> EIP-1965(https://eips.ethereum.org/EIPS/eip-1965)
       - 체인ID(서로 다른 체인간 트랜잭션 재생을 방지하는 수단)가 특정 블록넘버에서 유효한지 확인하는 방법을 개선하는 것으로, 특정 체인ID가 특정 블록넘버에서 유효한지여부를 알려주는 프리컴파일을 추가한다.

     12> EIP-1702(https://eips.ethereum.org/EIPS/eip-1702)   *최종승인됨(63차 회의)
       - 일반화된 계정버전 관리를 위한 것으로, EVM의 여러버전을 동일한 블록에서 실행할 수있게하여 기존 계정의 정확한 기능을 유지하면서도 HF를 용이하게 한다.

     13> EIP-1706(https://eips.ethereum.org/EIPS/eip-1706)
       - 가스비가 집행비(Call stipend)보다 낮은경우 SSTORE사용을 불가능하게 하자는 제안으로, 이더리움 프로토콜에 긍정적인 효과가 있을수도 있다.

     14> EIP-1803(https://eips.ethereum.org/EIPS/eip-1803)
       - 보다 직관적으로 보이게 하기 위하여 NUMBER, GASLIMIT, GAS 등의 opcode를 각각 BLOCKNUMBER, BLOCKGASLIMIT, GASLEFT 등으로 적절하게 명명한다.

     15> EIP-1829(https://eips.ethereum.org/EIPS/eip-1829)
       - 타원곡선선형조합에 대한 프리컴파일(Precompile for Elliptic Curve Linear Combinations)이다. '이더리움 트랜잭션에 디지털 서명시, 송신자는 그 트랜잭션(거래)에 대한 진위를 수신자에게 확신시킬때 필요한 방정식이 있고, 그것을 사전에 컴파일링하는 방법에 대한 논의'라고 보면 된다.
(자세한 설명은 여기글 후반부를 참조)

     16> EIP-1884(https://github.com/ethereum/EIPs/blob/dcc573e74adc0e6dd25821ddaabf862e8f85e107/EIPS/eip-1884.md)
       - 가스소비와 자원소비 간 균형을 맟추기 위하여 특정 opcode를 제안하며, 적절한 균형은 블록가스제한을 극대화하고 처리시간이 안정화되는 효과가 있다.

     17> EIP-1930(https://eips.ethereum.org/EIPS/eip-1930)
       - 엄격한 가스 의미구조를 지닌 CALL함수 적용 제안으로, 특정 가스량의 CALL을 실행시키는 스마트 컨트렉트를 추가한다. 현재 CALL시행함수들은 전송중인 가스를 시행하지 않고 단순히 가스값을 최대값으로 그대로 간주하는데, 이는 정확한 가스량을 사용하는 어플리케이션에 심각한 문제를 야기할수 있기때문에 개선제안되었다.

     18> EIP-1985(https://eips.ethereum.org/EIPS/eip-1985)
       - 가스제한, 블록넘버 등 EVM 매개변수들에 대한 적정 한계범위를 적용한다. 명시적인 범위를 적용하면 호환가능한 클라이언트를 구현하는데 도움이 된다.

     19> EIP-1959(https://eips.ethereum.org/EIPS/eip-1959)
       - 하나의 체인ID(서로 다른 체인간 트랜잭션 재생을 방지하는 수단)가 체인ID히스토리에 포함되어있는지 확인하는 새로운 opcode를 제안한다. 이는 오프체인 메세지가 다른 체인에서 재사용되지 않도록 보호하기 위함이다.

     20> EIP-1962(https://eips.ethereum.org/EIPS/eip-1962)
       - 타원 산술 및 런타임 정의와 결합에 대한 개선안으로, EIP-1829에 대한 확장안이며 EIP-1109에서의 SATICCAL opcode보다 작업비용이 더 저렴하다.

     21> EIP-2014(https://eips.ethereum.org/EIPS/eip-2014)
       - 확장된 스테이트 오라클이라는 확장가능한 인터페이스를 갖춘 새로운 시스템을 도입하여 체인식별자, 블록해시 등과 같은 확장된 데이터세트에 접근가능하다.

     22> EIP-2026(https://eips.ethereum.org/EIPS/eip-2026)
      - 계정에 대한 고정 선불제(스테이트 렌트B)로, 말그래도 신규계좌를 생선시 고정적으로 일회성 임대료 선불을 부과한다.

     23> EIP-2027(https://eips.ethereum.org/EIPS/eip-2027)
      - 인터넷 컨트렉트규모 계산(스테이트 렌트H)방식이다. 이더리움은 컨트렉트에 채워지거나 비워진 스토리지
슬롯갯수를 계산하는데, 기존의 슬롯갯수가 현재시점으로 계산하지 않기때문에 슬롯갯수의 순수 변화만
효율적으로 추적하는데, 이 개선으로 총 스토리지 슬롯갯수를 추적하게 된다.

     24> EIP-2028(https://eips.ethereum.org/EIPS/eip-2028)
       - Calldata(이더리움 상에서 트랜잭션 요청시 전송 데이트가 저장되는 곳)의 가스비를 현행 바이트 당 68에서 줄인다. Calladata비용이 절감되면 잠재적으로 더 큰 블록이 생겨 네트워크 지연이 증가하지만, 수학적 모델링과 경험적 추정에 의해 네트워크 보안이 강해지고 확장성이 증가되는 부수적인 효과가 있을수도 있다.

     25> EIP-2029(https://eips.ethereum.org/EIPS/eip-2029)
       - 스테이트 카운터 컨트렉트(스테이트 렌트A)도입으로, 다양한 상태 카운터가 저장될수있는 이더리움상의 어떤 장소로 안내한다.

     26> EIP-2031(https://eips.ethereum.org/EIPS/eip-2031)
       - 총 트랜잭션 카운터(스테이트 렌트B)에 대한 개선안으로, 오로지 변경된 트랜잭션수만 알게되는 현재와는 달리 스테이트 내부의 트랜잭션 수를 추척하게 된다.

     27> EIP-2035(https://eips.ethereum.org/EIPS/eip-2035)
       - 블록검증을 위해 SLOAD와 SSTORE실행시 지불해야하는 가격 재책정방식으로, 컨트렉트 스토리지 크기에 따라 비용이 달라진다(가령, 컨트렉트가 작을수록 저렴해진다).

     28> EIP-2046(https://eips.ethereum.org/EIPS/eip-2046)
       - 프리컴파일에 대한 정적호출의 가스비를 줄여, 파일사용이 보다 효율적이게 된다.

     추가> EIP-2024(https://github.com/ethereum/EIPs/pull/2024/files)   *최종승인됨(63차 회의)
       - BLAKE2b라는 새로운 암호화 해싱 알고리듬을 구현하는 사전컴파일 컨트렉트를 EVM에 도입한다.


□ 개인 논평

  ㅇ 가까운 미래의 이더리움
    - 최근 이더리움2.0스펙이 확정(관련 정보는 여기 클릭)되었고 이미 이더리움 관계자가 비트코인 출시 11주년인 2020년 1월 3일에 이더리움2.0의 0단계를 개시할수도 있다는 언급도 있었다. 물론 필자의 사견으로, 2020년 초에는 0단계 개시가 결코 쉽지않을것이라고 보지만 지연(delay) 역시 개발의 과정이라고 생각하기에 조급해하지 않으려 한다(필자가 연초에 작성한 2019 이더리움 로드맵은 여기 클릭)
    - 이더리움2.0 스펙이 확정된 6월말과 이더리움2.0 0단계 개시사이에는 이스탄불HF와 데브콘5라는 빅 이벤트가 있다. 최근의 이더리움 개발자 회의에 주로 논의되는 내용이 바로 이 이스탄불HF에 적용시킬 EIP를 선정하는 작업이며 각 EIP담당자들은 본인의 프로젝트 작업외에도 이더리움 개선을 위해 오늘도 개발작업에 고군분투하고 있다. 이스탄불HF 바로 이전에 치뤄질 이번 데브콘5가 특히 기다려지는 이유는 바로 '예치금 계약식(Deposit Contract Ceremony)'가 예정되어있기 때문이다. 이는 1) 비콘체인이 출현할 0단계에 앞서서 안정적으로 예치금을 확보하고, 미리 예치금을 확보함으로써 2) 네트워크 안정성 및 이자율에 대한 파악을 미리 하여 여러 시뮬레이션을 할수 있고, 3) 잘못된 예치주소로 예치금을 전송하는 것을 방지하기 위해 정확한 특정주소로 전송하는 것을 안내할수 있다. 현재 이더리움 측에서는 2백만 이더가 예치되길 바라고 있으며, 예치금에 따른 이더 발행 금리표는 다음과 같다.
< 비탈릭이 정리한 PoS기반 이더 발행 금리표 (https://github.com/ethereum/eth2.0-specs/pull/971) >

    - 이스탄불HF가 지연없이 잘 완료되고 곧바로 데브콘5에서 예치금 계약식 등을 통해 이더리움2.0 분위기를 조성하면서 2020년에 이더리움2.0이 문제없이 출시되면 이더리움 네트워크와 커뮤니티가 새로운 도약을 함은 물론 투자자들에게도 기다림에 대한 충분한 보상이 있을거라고 여겨진다. 잠시 분석가 마인드를 내려놓고 투자자의 관점으로 볼때, 재작년의 이더리움 시세 폭등과 작년의 끝없는 이더 시세의 하락을 목격했던 바, 올해 말까지 시장은 이더리움을 어떻게 평가할지 사뭇 기대된다.


법적 고지 : 본 게시글은, 투자를 위한 정보제공을 목적으로 작성되었기에 투자결정은 신중을 기하여 주시기 바라며, 참고자료를 토대로 본인 판단하에 내용을 추가, 편집 등 작성되었기에 본인의 허락없이 복사, 배포, 편집 등을 할 수 없습니다.

댓글

이 블로그의 인기 게시물

[Rave]Raven Devs Meeting(5 July, 2019) // 레이븐 개발자 회의 분석 및 논평(5 July, 2019) v1.0

[Insight] JP모건을 통해 본 월가와 코인시장(2부작) 1부 // Wallstreet and CryptoMarket with JPmorgan part1 v1.2

[Insight] JP모건을 통해 본 월가와 코인시장(2부작) 2부 // Wallstreet and CryptoMarket with JPmorgan part2 v1.3