[Ethereum] '제63차 이더리움 개발자 회의' 분석 및 개인 논평(6월 21일) v1.0

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

https://github.com/ethereum/pm/issues/102



□ 지난 회의 리뷰(+추가 검토)

  ㅇ 협의한 사안과 결정
    - EIP-1108을 이스탄불HF에 적용하기로 임시승인(a tentative approval)하고, 최종승인될때까지 추가 검토가 필요하다.

  ㅇ EIP-1109(https://eips.ethereum.org/EIPS/eip-1109)
    - PRECOMPILEDCALL이라는 특정 opcode를 생성하여, 일반 CALL실행시 어떤 비용없이 프리컴파일된 컨트렉트를 호출하게한다. 이는 프리컴파일된 컨트렉트들을 호출할때 높은 가스 소비를 하게되는 문제를 해결하기 위함이다.
    - 이 EIP는 오래전에 제안되었지만 내용을 많이 바꿨고 이번에 제대로 제안하여 다가올 HF에 적용하기로 하였다.

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

  ㅇ EIP-1283(https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1283.md)
    - 기존 콘스탄티노플HF에 적용될뻔한 EIP로, 총 가스 계량기(Net gas metering)를 변경하여 컨트렉트 저장소를 위한 새로운 활용가능성과 대부분의 작동방식이 안 맞을때 발생하는 과도한 가스비 감소에 도움이 된다. 즉, 불필요한 가스비를 줄이는 코딩을 가능케한다.
    - EIP-1706와 관련되어있는 기존 콘스탄티토플HF 적용 후보EIP로, 그때에 비해 큰 변화는 없으며 관련 개발자가 추가되었다. 다만, 이스탄불HF에 적용시 이 두 EIP(1706, 1283)가 결합되어 적용될수도 있으나 아직 합의가 되지 않기 때문에 검토가 필요하지만, EIP-1283은 지난 HF에도 적용될수도 있었던 제안으로, 이미 준비가 되었기에 이스탄불HF적용되었으면 한다. 그전에 EIP-1283팀 간에 합의를 통해 최종 의견을 내세울테니 그때 최종승인할지 다뤘으면 한다.

  ㅇ EIP-2045(https://github.com/ewasm/benchmarking)
     - 블록가스한도를 높이는(스토리지opcode비용을 높이는) 대신 계산opcode 가스비를 절감한다.
     - 최적화된 인터프리터에서 EVM바이트코드를 실행(evmone)해보니 꽤 괜찮은 성능을 보여주었다.
     - 이스탄불HF 적용을 위해 아직까지 개발자 회의에 소개할 내용은 충분하지 않는 실정이며, 계속 같이 논의하기로 하자.

  ㅇ EIP-2024(https://github.com/ethereum/EIPs/pull/2024/files)
    - BLAKE2b라는 새로운 암호화 해싱 알고리듬을 구현하는 사전컴파일 컨트렉트를 EVM에 도입하는 것으로, 이 BLAKE2b는 SHA해시함수보다 빠르고 효율적이며, SHA-3을 보완 및 대체가능하다. 또한 이 알고리듬은 64bit CPU에 최적화되어있고, Zcash블록체인과 EVM간 상호 운용성을 개선하고 IPFS와의 통합을 지원한다.
     - 이 알고리듬을 효율적으로 사용하면, Zcash에서 사용하는 Equihash에 의한 검증이 가능하며, 이더리움 상에서 BTC relay SPV방식*을 가능케하기도 한다.
      *BTC relay : 비트코인을 사용하여 이더리움 기반의 서비스를 이용케하는 체인간 중계 프레임워크로, 중계시 비트코인 풀노드(블록체인상 모든 블록정보를 저장하고 채굴하면서 새로운 블록을 생성하는 노드)를 모니터링 및 저장하는 중계자(relayer)가 있다. 그런데 풀노드의 모든 블록정보를 스마트컨트렉에 저장하기에는 너무 비효율적이므로 블록헤더만 저장하여 유효성 검증하는 SPV(Simplified Payment Verification)방식으로 비트코인 정보를 이더리움의 스마트컨트렉에 기록한다. 이때 더 간편한 SPV방식 덕분에 더 효율적인 유효성 검증이 가능하며, 수수료가 발생하기에 중계자들은 중계하는 행위에 동기부여가 되며, 결국 이러한 과정을 통하여 비트코인을 사용하여 이더리움 어플리케이션을 실행할수 있다.


□ 로드맵(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)
       - BLAKE2b라는 새로운 암호화 해싱 알고리듬을 구현하는 사전컴파일 컨트렉트를 EVM에 도입한다.

□ 개인 논평

  ㅇ 이더리움 오케스트라 '이스탄불 협주곡 제2악장'
    - 오케스트라는 관현악 연주를 목적으로 하는 집단적 연주 형태로, 최근의 이더리움 개발자 회의를 보며 하나의 오케스트라와 같다는 생각이 들었다. 각각의 이더리움 핵심개발자들은 다가올 이스탄불HF에 들어갈 EIP에 대해서 검토하고 적용할지에 대하여 논의하여 하나의 목적을 향해 매진하는 모습이, 각자의 악기를 다루며 화음을 만드는 오케스트라 같았다. 따라서 이 연주곡을 다가오는 HF인 '이스탄불'로 표현했고, 2주째 EIP에 대해 논의해서 2악장이라고 표현했다.
    - 물론 그 연주의 화음이 듣기좋을지 불협화음일지는 두고 봐야겠다. 지난 콘스탄티노플HF만 봤듯이 몇개의 EIP를 메인넷에 적용시키는 것이 얼마나 많은 검토, 논의, 테스트 그리고 EIP간 호환성이 필요한지 알 수 있다. 그러한 경험때문에 지금도 EIP를 제안한 개발자들은 열띤 논의를 하고 있는 실정이며, 내년으로 예정된 이더리움2.0의 0단계 이전에 이뤄지는 마지막 네트워크 업그레이드라 더욱 주목된다.

  ㅇ 역사를 잊은 커뮤니티에게 미래는 없다.
    - 앞서 얘기한것은 이더리움만의 내부사정이고, 눈을 외부로 돌리면 시간은 마냥 우리편이 아닌듯하다. 거대 금융사인 JP모건도 그렇고 거대 SNS업체인 페이스북도 그렇고 기존 기득권세력들의 행보가 점점 실체화되고 있어 블록체인 마을 원주민인 비트코인, 이더리움, 리플 등에 어떤 영향을 끼칠지 사뭇 궁금하다. 블록체인과 암호화폐에 대한 활용을 촉진하고 이미지를 향상하는데에는 도움이 되지만 또다시 특정집단이나 카르텔에 의해 대부분의 사용자들이 종속되는 역사가 반복될수도 있다. 이 시점에 우리는 어떻게 해야할까.
    - 우리는 여태까지의 역사를 통해 결국에 기득권의 세계는 항상 공고했으며 결국에 만인은 그들에게 종속될수 없다는 무기력한 학습을 해왔다. 아마도 기존 기득권세력이 블록체인 마을에 다가오는 현재, 그 무기력한 역사의 사슬을 조금이나마 끊을수 있는 시점일수도 있다. 따라서 탈중앙성, 투명성 등 각자 정의하는 것은 다르지만 우리가 옳다고 생각하는 사토시 정신을 기억하고, 그에 걸맞는 프로젝트를 지지하거나 때론 비판하는 등 각자 떨어져있지만 목소리를 내기를 필자는 제언하는 바다. 시간은 더욱 빨리가고 세상도 계속 변하는데 우리만 과거처럼 똑같을수만은 없지 않은가.


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

댓글 없음:

댓글 쓰기

[Bitcoin] 비트코인의 흥망성쇠(3부작) 1부 "역대 주요이슈 분석" // Bitcoin's Rise & Fall(Trilogy) Part1 v1.5

비트코인의 흥망성쇠 (興亡成衰) □ 에필로그   ㅇ 분석에 앞서     - 그동안 분석가로서 블록체인과 암호화폐가 지닌 기술 위주의 기본적 분석을 해왔으나, 투자자로서 유의미한 시세변동, 시세에 영향을 끼치는 이슈 등에 대한 분석글 작...