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

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

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



□ 이스탄불HF에 포함/미포함

  ㅇ EIP-1344 : 포함
   < 부연 설명 >
    - EIP-1344(https://eips.ethereum.org/EIPS/eip-1344)은 컴파일링시 체인ID(서로 다른 체인간 트랜잭션 재생을 방지하는 수단)를 지정하고 opcode를 추가하면 그 체인ID에 접근하여 서명의 유효성을 검사하며, 따라서 다른 체인간 리플레이 어택 등을 방지할수 있다.
   < 회의 내용 >
    - 서명의 유효성을 검사하기 위해 체인ID를 체인상에 포함시킬지 아니면 트랜잭션상에 포함시킬지에 대한 논의가 있었고, 스마트컨트렉트 사용시 같은 체인으로부터 다른 체인ID를 받는 가능성이 있을수 있기때문에 체인상에 포함하는게 더 안전할거라는 의견이 있었다. 이때, opcode를 추가하여 opcode를 호출하면 공개되지 않는 넘버가 나오고 그 넘버를 갖고있을때만 체인ID에 접근하여 서명의 유효성을 검사할 수 있다. 이 개선안은 합리적이라는데 대부분 공감하므로 이스탄불HF에 포함된다.

  ㅇ EIP-1283EIP-1706, 그리고 EIP-2200 : 포함
   < 부연 설명 >
    - EIP-1283(https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1283.md)은 지난 콘스탄티노플HF에 적용될뻔한 EIP로, 총 가스 계량기(Net gas metering)를 변경하여 스마트컨트렉트 저장소를 위한 새로운 활용가능성과 대부분의 작동방식이 맞지 않을때 발생하는 과도한 가스비의 감소를 목표로 한다. 즉, 불필요한 가스비를 줄이는 코딩을 돕는다.
    - EIP-1706은 이스탄불HF를 위한 EIP-1283수정본으로, 가스비가 집행비(Call stipend)보다 낮은경우 SSTORE사용을 불가능하게 하자는 제안이다.
    - EIP-2200은 EIP-1283과 EIP-1706의 통합본으로 이스탄불HF에 적용시 이 두 EIP(1706, 1283)가 결합된다.
   < 회의 내용 >
    - EIP-1283은 상대적으로 간단한 개선안이며, EIP-1706를 보더라도 많은 변화가 있지는 않다. 지난 콘스탄티노플HF때도 도입될뻔한 개선안이므로 딱히 결함이 없다면 이스탄불HF에 포함시키지 않을 이유가 없다. 다만, 1283개선안을 선택할지 아니면 1706개선안을 선택할지에 대한 것은 논의가 필요하다. 어떤 버전의 EVM과도 호환가능한 개선안이 좋을것같고, 그런의미에서 2200개선안이 제일 나아보인다. 결론적으로 기술적으로 구현할 시간이 충분한지 살펴보고, 실행해보면서 유의미한 효과가 있는지 보기로 하고 이스탄불HF에는 포함시키기로 한다.

  ㅇ "ProgPoW" EIP-1057 : 보류
    - ProgPoW(https://eips.ethereum.org/EIPS/eip-1057)는 특정ASIC이 채굴할수 있는 작업유효간격을 좁히기 위해 고안된 PoW알고리듬으로, ASIC의 향상된 효율성을 반감시키위하여, 상용GPU자원을 최대한 활용되도록 수정하는 것이 ProgPow의 디자인이다.
   < 부연 설명 >
    - 우선 ProgPow는 ASIC채굴의 상대적 높은 효율성을 반감시키는 PoW변형알고리듬으로, AMD, NVIDIA 등이 제조하는 그래픽 카드에서 테스트되고 적용되며, 따라서 카드제조업체 및 산업에 적지않은 영향을 줄수 있고, 동시에 이더리움 전체 해시레이트와 연관이 있으며, 채굴에도 영향을 끼친다.
    - 현재 Ethash의 경우, 범용 GPU가 메모리 활용시 약 60%정도만 활용하기에 비효율적인데 반해 FPGA나 ASIC은 이런 비효율적인 메모리 활용을 임의설계하여 메모리 효율성을 높이기 때문에, 채굴 관점으로 보면 그 향상된 효율성이 곧 향상된 채산성으로 이어지게 되는 것이다.
    - 이에 ProgPow의 필요성이 대두되었고, ASIC의 향상된 효율성을 반감시키위하여, Ethash를 사용하면서도 상용GPU자원을 최대한 활용되도록 수정하는 것이 ProgPow의 디자인이다.
   < 회의 내용 >
    - (일전에 중단된) 감사가 진행되고 있고 8월말이나 9월초에 그 결과가 나온다. 우선 ProgPoW를 할경우 해시레이트 변동성과 같은 잠재적 문제들이 존재한다. 그리고 원래대로라면 이미 감사가 끝나고 검토까지 해야하지만 현재 상황을 보면 테스트넷HF를 할때까지 감사결과가 나오기 어렵다. 이런 이유들 때문에, ProgPoW를 이스탄불HF대신에 내년 4월에 있을 차기HF 또는 별도의 HF를 할때 추진하는게 나을수도 있다. 일단 감사결과가 나올때 이 개선안이 테스트넷에 포함될수 있는지 기다리기로 한다.

  ㅇ EIP-1962 : 보류
   < 부연 설명 > 자세한 내용은 여기글 후반부 참조
    - 타원 산술 및 런타임 정의와 결합에 대한 개선안으로, EIP-1829*에 대한 확장안이며 EIP-1109에서의 SATICCAL opcode보다 작업비용이 더 저렴하다.
    *  EIP-1829(https://eips.ethereum.org/EIPS/eip-1829) : 타원곡선선형조합에 대한 프리컴파일(Precompile for Elliptic Curve Linear Combinations)임. 이더리움 트랜잭션에 디지털 서명시, 송신자는 그 트랜잭션(거래)에 대한 진위를 수신자에게 확신시킬때 필요한 방정식이 있는데, 그것을 '사전에 컴파일링하는 방법에 대한 논의'라고 보면 됨.
   < 회의 내용 >
    - EIP-1962(https://eips.ethereum.org/EIPS/eip-1962)와 관련해서는, 각 오퍼레이션마다 서로 다른 프리컴파일을 호출해야하는 가에 대한 쟁점이 있다. 현재는 오퍼레이션마다 다른 프리컴파일을 호출하는데에 합의가 되었고 병렬처리도 현행유지(32)가 좋을것 같다는 의견이 있었다. 또한, 테스트넷HF까지 2주정도 남았는데 그 기한을 지키기는 어려울것같다. 우리는 이미 다른 (코딩) 언어로 2개의 실행결과물을 얻었고, 누군가 원하면 또다른 언어로 만들수도 있다. 중요한것은 프리컴파일에 대한 기준을 정하는건데, (이더리움2.0에서 가동될) 비콘체인을 위한 기준을 정한다면 (장기적으로도) 좋을것같다.
    - 일정을 따르는 것에 대해서는, 기한을 지키는 것은 중요하지만 현재 추진중인 EIP를 현행 로드맵에 적용했을때 시간이 충분한 것은 거의 없을것이다. 따라서 우선 가장 간단한 실행결과물을 성취하면서 추가적인 개선을 이어가는게 좋을것이다. 이스탄불HF의 주요 개선사항은, '체인ID', '가스비 감소'가 될것이며 '프리컴파일'도 마찬가지다.

  ㅇ테스트넷HF와 이스탄불HF 일정 관련 
    - 이스탄불HF의 주요 개선안들 중에서는 기존의 HF일정을 맞출수 있는게 있는 반면 맞출수있는지 가늠이 안되는게 있다. 따라서 우리에겐 2가지 선택지가 있으며, 하나는 HF일정을 지연시키는 것이고 다른 하나는 원래 HF일정을 무슨일이 있어도 키지는 것이다. 만약 또다른 선택지가 있다면 현행 HF일정을 지키되 새로운HF를 추가 진행하는것이다. 즉, 이스탄불HF이후 차기HF를 2020년 4월이 아닌 1월과 7월에 진행시키되 이스탄불HF때 부득이하게 추가하지 못한 EIP를 1월HF때 적용하는 것이다. 하지만 10월로 예정된 이스탄불HF이후 3개월만에 또다른 HF를 하는 것은 개발자의 개발진행으로나 클라이언트의 적응에 빡빡하다는 단점이 존재한다.
    - 우리가 특히 당장 걱정해야하는 것은 8월 중순에 예정되어있는 테스트넷HF다. 객관적으로 볼때, 예정대로 진행한다면 중요성이 떨어지는 EIP들만 적용될것이다. 따라서 최소한 테스트넷HF일정을 지연시키는게 바람직하며, 이스탄불HF는 가급적 원안대로 이행해보기로 한다.

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

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


□ 개인 논평

  ㅇ 현재까지의 이스탄불HF 결정 사안
    - 테스트넷HF가 기존 8월 14일(수)에서 9월 4일(수)로 지연되었다. 이 HF에 포함에 확정안은 5가지*이다.
     1) EIP-1108 : alt_bn128 프리컴파일 가스비 절감제안. 값비싼 타원곡선산술 사전컴파일을 재평가하여 개인정보보호와 확장성을 개선.
     2) EIP-2024 : BLAKE2b라는 새로운 암호화 해싱 알고리듬을 구현하는 사전컴파일 컨트렉트를 EVM에 도입.
     3) EIP-2028 : Calldata(이더리움 상에서 트랜잭션 요청시 전송 데이터가 저장되는 곳)의 가스비를 현행보다 감소. Calladata비용이 절감되면 잠재적으로 더 큰 블록이 생겨 네트워크 지연이 증가하지만, 수학적 모델링과 경험적 추정에 의해 네트워크 보안이 강해지고 확장성이 증가되는 부수적인 효과가 있을수도 있음.
     4) EIP-1344 : 컴파일링시 체인ID(서로 다른 체인간 트랜잭션 재생을 방지하는 수단)를 지정하고 opcode를 추가하여 그 체인ID에 접근하여 서명의 유효성을 검사하며, 다른 체인간 리플레이 어택 등을 방지.
     5) EIP-1702 : 일반화된 계정버전 관리를 위한 것으로, EVM의 여러버전을 동일한 블록에서 실행할 수있게하여 기존 계정의 정확한 기능을 유지하면서도 HF를 용이하게 함.
    - 또한 테스트넷HF에 포함될수도 있는 '잠정보류'건은 다음과 같다.
     1) EIP-2200(EIP-1283 + EIP-1706) : 총 가스 계량기(Net gas metering)를 변경하여 스마트컨트렉트 저장소를 위한 새로운 활용가능성과 대부분의 작동방식이 맞지 않을때 발생하는 과도한 가스비를 감소. 또한, 가스비가 집행비(Call stipend)보다 낮은경우 SSTORE사용을 불허함.
     2) EIP-1962 : 타원 산술 및 런타임 정의와 결합에 대한 개선안으로, EIP-1829에 대한 확장안이며 EIP-1109에서의 SATICCAL opcode보다 작업비용이 더 저렴.
     3) EIP-1057 : ProgPoW로 불리며, ASIC의 향상된 효율성을 반감시키위하여, 상용GPU자원을 최대한 활용되도록 수정.
     4) EIP-1884 : 가스소비와 자원소비 간 균형을 맟추어 블록가스제한을 극대화하고 처리시간이 안정화.

  ㅇ 이더리움과 라이트닝 네트워크
    - 지난 7월초에 부테린이 이더리움 네트워크 확장을 위해 비트코인캐시 블록체인을 사용하자는 제안이 있었다. 그런데 얼마 지나지 않아 최근에는 그는 트위터를 통하여 이더리움 스마트 컨트렉과 비트코인의 라이트닝 네트워크의 통합을 지지한다고 말했다. 이는 Blockade Games가 곧 출시할 이더리움 기반 RPG게임을 자체 테스트넷에서 통합을 전개한 것에 따른 것이다.
    - 아시다시피 라이트닝 네트워크는 비트코인의 오프체인 확장성 솔루션(Off-chain Scaling Solution)으로, 블록체인 바깥에서 사용자간 결제채널을 형성해 신속하고 수수료가 미비한 거래를 할수 있다 하여 제2레이어 결제 기술(The 2nd layer payment protocol)이라고도 한다. 7월만 보더라도 각 체인간 경계는 느슨해지고 있다. 본디 통합이라는 것은 각자의 장점을 취하고 단점을 보완하는 것이다. 본연의 정체성이 약간 훼손하더라고 그렇게 하는 이유는 블록체인 표준을 선점하는 것일수도 있고 블록체인 주도권을 잡기위해서 일수도 있다. 그 목적이 무엇이든간에 분명한것은 최우선 목적을 향한 개발은 수단과 방법을 가리지 않는다는 점이며 현재의 이더리움도 마찬가지이다. 그런의미에서 테스트넷HF, 이스탄불HF, 그리고 이더리움2.0을 앞둔 이더리움이 정체성유지와 지속된 향상의 적절한 균형(trade-off)를 잘 견지할수 있을지 우리는 꾸준히 지켜봐야할것이다.


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

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

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

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

 ※ 모든 EIP는 해당EIP에 대한 참조 구현(코드)가 있거나 대변자가 성공적으로 필요성을 주장하는 한, 금번 회의에 이스탄불로 여정의 기로에 서 있을것입니다. 이스탄불로 가지 못하는 EIP는 차기 HF에 반영될수 있습니다.



□ 이스탄불 여정의 동행자 최종 후보

  ㅇ EIP-615(https://eips.ethereum.org/EIPS/eip-615) 
     - EVM을 위한 서브루틴(subroutines) 및 정적 점프(static jumps)다. '서브루틴과 연산기법을 도입하여 성능향상 등 검증의 최적화를 위한 작업'정도라고 보면 된다.
   < 부연 설명 > 자세한 내용은 여기글 후반부 참조
    - 블록체인은 자세한 설명과 검증이 필수인데, EVM*설계 상 그것들을 하기 어렵고, 낮은가스비 및 고성능실행 역시 적용이 어렵다. 현재 EVM은 동적 점프**(dynamic jump)를 지원하는데, 이경우 어디로 점프할지 스택상 명확하지 않다. 따라서, 정확성 증명, 정적 분석, 컴파일 최척화 등을 저해하는 동적 점프 사용을 지양하고, 이를 대체하기 위한 서브루틴과 몇가지 다른연산을 도입하고자 하며, 이를 통해 성능향상 등 이점을 제공하면서도, EVM성능한계를 시험할수
있을것이다.
     * EVM(Ethereum Vitrual Machine, 이더리움 가상 머신) : 이더리움을 전체를 작동하는 엔진으로, 수많은 토큰과 디앱 등을 책임짐.
     ** 점프(jump) : EVM의 컨트렉트 함수는 내외부, 재귀 호출 등 여러가지인데, 이 중에서 내부함수를 효율적으로 호출하는 연산코드로 프로그램 카운터(PC)를 이동하여 다른 바이트코드(bytecode)를 실행함.
     - 첨언하자면, 나중에 eWasm이 도입되겠지만 그럼에도 어쨌든 현재 가동중인 EVM을 개선될 필요가 있고 근본적으로 동적 점프를 제거할수는 없겠지만 대신에 정적점프를 사용하고 그덕분에 대부분의 언어로 사용자를 이동시킬수 있으며, 결국 이러한 EVM변경 덕분에 wasm으로 쉽게 이동(porting)도 가능할것이다. 이를 위해서, 서브루틴 추가, 정적점프 연산코드 추가, 커뮤니티 교육을 통한 동적점프 사용 빈도 낮추기 등이 필요할것이다.
   < 회의 내용 >
    - 현재로서는 EIP-615를 이스탄불HF에 적용하지는 않겠지만, 최종 적용여부를 위하여 추가 테스트를 할것이다.

  ㅇ EIP-1344 vs. EIP-1965 'EIP-1965와는 별개로 EIP-1344에 대한 (HF적용) 결정을 할수 있는가'
   < 부연 설명 >
    - EIP-1344(https://eips.ethereum.org/EIPS/eip-1344)은 컴파일링시 체인ID(서로 다른 체인간 트랜잭션 재생을 방지하는 수단)를 지정하고 opcode를 추가하면 그 체인ID에 접근하여 서명의 유효성을 검사하며, 따라서 다른 체인간 리플레이 어택 등을 방지할수 있다.
    -  EIP-1965(https://eips.ethereum.org/EIPS/eip-1965)은 체인ID가 특정 블록넘버에서 유효한지 확인하는 방법을 개선하는 것으로, 특정 체인ID가 특정 블록넘버에서 유효한지여부를 알려주는 프리컴파일을 추가한다.
   < 회의 내용 >
    - 정의, 실행 등에 대한 불확실성으로 인해 이스탄불HF 적용하지 않을 것이다.

  ㅇ EIP-1283(https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1283.md)
   < 부연 설명 >
    - 기존 콘스탄티노플HF에 적용될뻔한 EIP로, 총 가스 계량기(Net gas metering)를 변경하여 컨트렉트 저장소를 위한 새로운 활용가능성과 대부분의 작동방식이 맞지 않을때 발생하는 과도한 가스비의 감소를 목표로 한다. 한마디로, 불필요한 가스비를 줄이는 코딩을 가능케한다.
    - 참고로 EIP-1283는 완화제같은 역할을 하는 EIP-1706와 관련되어있는 기존 콘스탄티토플HF 적용 후보EIP로, 그때에 비해 큰 변화는 없으며 관련 개발자가 추가되었다. 다만, 이스탄불HF에 적용시 이 두 EIP(1706, 1283)가 결합되어 적용될지는 합의가 필요하나, EIP-1283이 이스탄불HF에 적용될지에 대해선 지난 HF에도 적용될수도 있었던 만큼 이미 준비가 되었다고 본다.
     * EIP-1706(https://eips.ethereum.org/EIPS/eip-1706) : 가스비가 집행비(Call stipend)보다 낮은경우 SSTORE사용을 불가능하게 하자는 제안.
   < 회의 내용 >
    - EIP-1283와 EIP-1706의 결합 등에 대한 일반적인 합의가 도출되지 않아 추가 논의를 하기로 한다.

  ㅇ EIP-1962(https://eips.ethereum.org/EIPS/eip-1962)
   < 부연 설명 > 자세한 내용은 여기글 후반부 참조
    - 타원 산술 및 런타임 정의와 결합에 대한 개선안으로, EIP-1829*에 대한 확장안이며 EIP-1109에서의 SATICCAL opcode보다 작업비용이 더 저렴하다.
    * EIP-1829(https://eips.ethereum.org/EIPS/eip-1829) : 타원곡선선형조합에 대한 프리컴파일(Precompile for Elliptic Curve Linear Combinations)임. 이더리움 트랜잭션에 디지털 서명시, 송신자는 그 트랜잭션(거래)에 대한 진위를 수신자에게 확신시킬때 필요한 방정식이 있는데, 그것을 '사전에 컴파일링하는 방법에 대한 논의'라고 보면 됨.
   < 회의 내용 >
    - HF적용 결정을 유보하고 온오프라인 상으로 추가 논의가 필요하다.

  ㅇ EIP-2028(https://eips.ethereum.org/EIPS/eip-2028)
   < 부연 설명 >
    - Calldata(이더리움 상에서 트랜잭션 요청시 전송 데이터가 저장되는 곳)의 가스비를 현행 바이트 당 68에서 더 감소시킨다. Calladata비용이 절감되면 잠재적으로 더 큰 블록이 생겨 네트워크 지연이 증가하지만, 수학적 모델링과 경험적 추정에 의해 네트워크 보안이 강해지고 확장성이 증가되는 부수적인 효과가 있을수도 있다.
   < 회의 내용 >
    - 이스탄불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방식 덕분에 더 효율적인 유효성 검증이 가능하며, 수수료가 발생하기에 중계자들은 중계하는 행위에 동기부여가 되며, 결국 이러한 과정을 통하여 비트코인을 사용하여 이더리움 어플리케이션을 실행할수 있다.
   < 회의 내용 >
    - 지난 63차 회의때 이미 이스탄불HF적용을 확정지었다.

  ㅇ 기타 다른 EIP 검토
   < State Rent 관련 EIP >
    - 아직 결정된것은 없지만 아마도 다음기회(어떤HF가 될지는 모르겠지만)를 노려야할것이다.
   < ProgPoW > EIP-1057(https://eips.ethereum.org/EIPS/eip-1057)
    - ProgPoW는 특정ASIC이 채굴할수 있는 작업유효간격을 좁히기 위해 고안된 PoW알고리듬으로, ASIC의 향상된 효율성을 반감시키위하여, 상용GPU자원을 최대한 활용되도록 수정하는 것이 ProgPow의 디자인이다.
   < 부연 설명 >
    - 우선 ProgPow는 ASIC채굴의 상대적 높은 효율성을 반감시키는 PoW변형알고리듬으로, AMD, NVIDIA 등이 제조하는 그래픽 카드에서 테스트되고 적용되며, 따라서 카드제조업체 및 산업에 적지않은 영향을 줄수 있고, 동시에 이더리움 전체 해시레이트와 연관이 있으며, 채굴에도 영향을 끼친다.
    - 현재 Ethash의 경우, 범용 GPU가 메모리 활용시 약 60%정도만 활용하기에 비효율적인데 반해 FPGA나 ASIC은 이런 비효율적인 메모리 활용을 임의설계하여 메모리 효율성을 높이기 때문에, 채굴 관점으로 보면 그 향상된 효율성이 곧 향상된 채산성으로 이어지게 되는 것이다.
    - 이에 ProgPow의 필요성이 대두되었고, ASIC의 향상된 효율성을 반감시키위하여, Ethash를 사용하면서도 상용GPU자원을 최대한 활용되도록 수정하는 것이 ProgPow의 디자인이다.
   < 회의 내용 >
    - (일전에 중단된) 감사가 재진행되기를 기다려야한다면, 일정상 이스탄불HF적용은 어려울것으로 보인다. 다만, ProgPoW만을 위한 'Single EIP HF'가 있을수 있으며 상황을 보며 논의를 이어가기로 한다.

  ㅇ 나머지 EIP는 이스탄불HF에서 제외되는가
    - 앞서 이스탄불HF 적용 확정여부를 결정한 것 이외에는, 참조 구현이나 대변자가 없으면 HF 미적용이며 추가논의가 필요한 EIP에 대해서는 다음 회의때 다루기로 한다.


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

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


□ 개인 논평

  ㅇ 이더리움 네트워크 개선 전략
    - 금번 개발자 회의에 대해서는 딱히 할말이 없기에 다른 관점으로 논평해보겠다. 예전부터 느낀거지만 이더리움 개발 회의, 커뮤니티, 각종 뉴스 등을 통해 현재 이더리움의 최우선 과제들 중 하나는 '확장성 높이기'다. 뭐 하루이틀 이슈된 것이 아니기 때문에 새로운 것도 없지만 이더리움의 개발 방향을 보면 최우선 과제들을 해결하려는 매일매일이 새롭고, 확장성 측면도 마찬가지다.
    - 이더리움2.0은 다양한 목표와 비전을 목표로 하고 있으며, 장기적으로 초당 10MB이상 데이터 처리가능한 데이터 레이어를 확보하는 '확장성 향상' 목표를 갖고 있다. 그런데 최근 이더리움 창시자 부테린은 한 게시물(보기 클릭)을 통해 단기적인 확장성 솔루션을 제안했다. 바로 비트코인캐시 블록체인을 이더리움 네트워크 확장을 위해 사용하자는
아이디어였다.
    - 비트코인캐시 블록체인 활용의 이점들은 다음과 같다. 첫째, 경제성이다. 이더리움 체인보다 비트코인캐시 체인이 거래수수료가 낮다. 둘째, 높은 데이터 처리가 가능하다. 초당 최대 8KB까지 데이터를 처리하는 이더리움에 반해, 비트코인캐시는 초당 약 53KB까지 처리가능하다. 셋째, 즉시 개시가능한 전략이다. 놀랍게도, 이미 이더리움 네트워크 안애서 비트코인캐시의 블록을 검증하는 기술적 준비가 완료되었다. 넷째, 비트코인캐시의 개방성이다. 거래수수료를 지불만 한다면 어디에 써도 용인하기 때문이다. 물론, 비트코인캐시의 블록시간이 10분이나 되기 때문에 근본적인 확장성 솔루션으로 보기에 무리가 있지만 제로컨펌기술 등을 통해 보완가능하기도 하고 단기적인 솔루션이기 때문에 필자가 봐도 나쁘지 않은 아이디어라고 생각한다.

  ㅇ 커뮤니티의 반응과 역할
    - 이러한 부테린의 아이디어에 대한 커뮤니티의 반응은 어떨까. 부정적인 의견이 많으며 개인적인 반응도 마찬가지다. 그 이유로, 혹자는 비트코인캐시에 대한 반감이 있어서 그렇다고 하지만, 개인적으로는 단기적인 이익을 위하여 굳이 그럴 필요까지 있냐라는 생각이 우선 든다. 차용하려는 블록체인이 비트코인캐시든 다른것이든 상관없이, '실험을 위한 실험'은 또다른 부작용을 낳기 때문이다. 이더리움2.0까지 가지 않더라도 이더리움의 지속가능한 확장성 향상은 결코 쉽지 않은 '실험'이다. 그런데 그 실험의 과정에 다른 블록체인을 단기적인 이익을 위하여 '실험'의 '실험'을 한다는 것은 필자가 볼때 쉽게 납득이 되지 않는다. 불과 몇달전만 하더라도 단기 확장성 향상을 위하여 영지식증명을 활용한 온체인 확작성 솔루션이 소개되었다. 그 아이디어에 대해서는 긍정적이다. 왜냐면 익명성 기술은 확장성 외에도 개인정보보호 등 다른 이점들도 존재하고, 지속가능하며, 커뮤니티도 납득가능하기 때문이다.
    - 비트코인캐시 블록체인 활용 아이디어가 아직 공식적으로 확정도 안 된 마당에, 벌써부터 딴지를 걸고 싶은 마음은 아니지만 이더리움 측은 어떤 아이디어라도 개발자와 커뮤니티의 반응과 소통을 통해 지속가능하면서도 가장 많이 용인하는 방향으로 나아가기를 바란다. 따라서 그 과정에서 우리들 역시 지지든 비판이든 목소리를 내는 역할을 하는 것이 매우 중요하다. 


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

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



(English) 한국어 버전은 아래쪽에 있음

□ Analysis of the meeting by subject

  ㅇ C++ Developer Recruitment
    - Early in the meeting, Tron Black(Tron) said we are looking for a C++ dev to help out the core team. We would prefer them to be in the Utah office, but would consider remote for the right person.
     ※ In the current state of development of Raven, developers who are in charge of each function were sick or not be reached, which is harmful to its development. Therefore, hiring developers who are able to cantact at any time and work together would not to delay the roadmap schedule any longer.

  ㅇStory of DEX built by Bruce penton
    - A dev said, "I heard Bruce is buildinga DEX," and asked if it is ture. Tron responded he hadn't heard of it saying he deosn't know when, but it would be great if we had a DEX for Raven Coin. The dev who asked said Bruce on Feb 28, 2019, left a message saying, 'I’m looking for people to help build a DEX'.

  ㅇDevelopment progress
    - A dev asked about the progress of the development of features, and Tron said they are going well according to the road map, and that all functions were active on testnet. In particular, we expect Memo* to increase IPFS hash according to all transactions.
     * Memo is an immutable property associated with all transactions stored in IPFS by the messaging function. Once the messaging and memo function is completely tested, IPFS will be combined with IPFS and the IPFS where the data is stored will be activated with messaging and memos, then the IPFS hash will naturally added.

  ㅇ Tags and Restricted Assets
    - Before the devs discuss, I will explain the background of the tags and restricted assets. First, anyone can be an issuer that uses Raven network to register assets, but ownership of assets requires a certain amount of Raven, the name of the asset to register, and tags. For example, creating general unique assets(non-restricted assets) requires 500 ravencoin and the asset name must be unique. In addition, 1,500 raven is required to generate restricted assets, and it is expressed like $ABC, and can only be transferred with tagged addresses beginning with something like #. To preven confusion in the future, General unique assets(e.g., ABC) and restricted assets($ABC) should be different in terms of naming. Therefore, if someone wants to purchase and register restricted assets, a system may be built to register non-restricted assets first. In other words, it is kinda 'a package'.
    - (Back to the devs meeting) Tron said that only an issuer of the asset could freeze the restricted asset, and that it would cost a fee to burn tags and restricted assets. However, tags that serve as logical operations (and, or not) will not function as such rather than as burned. Anyway, the person who can get rid of tags is the token issuer related with the tag.
    - They also said that restricted assets of the same name (for example, $BALL) can be created only if someone has unique assets, or restricted assets(for example, BALL). Note that the cost of creating a restricted asset is 1500 ravencoin.

  ㅇ About anti-ASIC
    - Tron said that while custom hardware itself (such as ASIC) is not bad, such equipment causes centralization. As Raven devs, we are against ASIC, so those involved in ASIC will invade in secret.
    - Then Tron said, "The first stepis to mine Raven with CPU, the second stage to mine by GPUs, the third stage to have GPUs as well as FPGAs, the fourth stage to have GPUs, FPGAs, and a few ASIC, and the fifth stage predominantly ASICs. Tron said that we are now at 3, and some said at 4.
    - There are cases of botnet(malicious software planted to use someone's computer), but it is a matter of individuals and does not damage decentalization.
    - In addition, since making asics is hugely R&D and cost intensive so minor changes can ruin asics with designs currently in production, minor changes in algorithms can ruin ASIC mining. However, the sudden change in the algorithm can cause confusion among GPU miners and eventually affect network security. After all, minimal changes are best, but a big change is still good for anti-ASIC.


□ Personal review

  ㅇ Voice of Raven Community on ASIC
    - I introduced on previous personal review the survey on Raven(https://www.surveymonkey.com/r/W29S96N) and its results were released. Let's take a closer look at the results as it is as important as the Raven development.
    - First of all, it is about the type of Raven participation. Miners account for the largest portion, followed by owners. Even considering investors, there are more non-miners(holders, investors) than miners.
    - Second, it is about how many GPUs are mining Raven(only for miners). A majority of the respondents said they mine fewer than a dozen GPUs, while more than 10 percent said they mine with more than 50 GPUs.
    - Third, it is about whether they were in favor of ASICs, and an overwhelming majority of respondents said they were against ASICs.
    - Fourth, it is about whether you think the algorithm is worth changing (for ASIC resistance) even if Ravencoin chain is bifurcated and possibly exists as multiple chains. Various opinions were expressed in response. First of all, those in favor of changing the algorithm said thes: The reason why we supported Raven in the first place is that even individuals can mine then, and if ASIC is on, we, early supporters, feel abandoned. Also, Raven was designed from the beginnning with several sub-algorithms for ASIC resistance, we will lose Raven's identity if let ASIC dominates. On the other hand, opponents of the algorithm change said : If we have to change the algorithm to resist ASIC but have chances to have multi-chains, Raven project will have to choose. to be nor not to be.. And what's more important than ASIC is network security, not to achive decentalization, and if network security is destroyed, we will support ASIC mining rather than splitting its chain.
    - Fifth, it is about the question is what strategy should be established if ASIC mining is detected. The most popular strategy was to change the mining algorithm every six month, as was Monero's. The second most popular strategy was to (immediately) change the mining algorithm, and the third was to completely change it to GPU-specific algorithms like Ethereum's ProgPoW method.
    - Last sixtth, it is about whether ASIC mining was already in progress. While most of them answered that ASIC mining is not in progress, some believe that it is true through some analysis and showing some opinions.

  ㅇ Personal opinion about ASIC
    - I have monitored how Monero and Ethereum responded to ASIC's resistance. As for Raven, I guessed what strategy Raven will set to anti ASICs.
    - First of all, security of the network is the top priority, regardless of coin types. No matter how important ASIC resistance is, it cannot be as important as network survival. In order to survive the network, Monero set a strategy to change the mining algorithm every six month, and Ethereum is considering introducing a GPU-specific algorithm(ProgPoW) but has kinda 'no-strategy' that does not set any significant
strategy to date.
    - Looking at current trends, I think Raven is more likely to follow the Monero way and the reasons for this are as follows. First, devs including Tron are monitoring Monero's strategy. Second, Raven needs a strong rstrategy as it is designed to be inherently strong in ASIC resistance. Third, in a recent survey, the community also wants to change the algorithm. The problem is 'When ASICs invade' and we just hope to respond to ASICs after major functions such as tags, messaging, restricted assets and voting are activated on mainnet. Hopefully, Raven's devs and community will come up with a unified stance on ASIC resistance before too late.


(한국어)

□ 소재별 회의 내용

  ㅇ C++개발자 모집
    - 회의 초반에 트론 블랙(이하 'Tron')은 레이븐 핵심 개발팀에 합류할 C++개발자를 구하고 있다고 밝혔다. 조건은 유타 사무실에 근무가능한 개발자를 우선 고려하겠지만, 떨어져있어도 적합한 인물이라면 고려해보겠다고 말했다.
     ※ 필자주 : 레이븐 개발현황을 보면 동시다발적으로 여러 기능을 테스트중인데, 각 기능을 전담하는 개발자들이 종종 아프거나 연락이 닿지 않아 개발진행에 해가 되는 경우가 몇번 있었다. 이에 상시 근무하면서 즉시 소통가능한 개발자를 채용하는 것이 개발일정이 더이상 늦춰지지 않기 위한 일환으로 보여짐.

  ㅇ 브루스펜튼의 DEX 제작설
    - 한 개발자가 브루스펜튼(이하 'Bruce')이 DEX(탈중앙거래소)를 만든다는 애기를 들었다며 혹시 진행상황이 어떤지 물었다. Tron은 들은바가 없다면서, 그게 언제인지는 모르지만 레이븐코인을 위한 DEX가 생긴다면 참 좋을 것이라고 말했다. 질문한 개발자는 2019년 2월 28일에 Bruce가 'DEX를 만드는데 도움을 줄 사람을 찾는다'라는 메시지를 남겼다고 말했다.

  ㅇ 개발진행상황
    - 한 개발자가 레이븐 관련 기능들에 대한 개발진행상황을 물었고, Tron은 로드맵에 따른 순서대로 잘 진행되고 있으며, 모든 기능들이 테스트넷에 활성화되어있다고 말했다. 특히 메모*가 모든 트랜잭션에 따라 IPFS해시를 늘릴것으로 기대한다고 말했다.
     * 메모(Memos)는 메시징 기능에 의해 IPFS에 저장된 모든 트랜잭션과 연결되는 변경 불가능한 속성으로 메시징기능과 메모기능의 테스트가 완료되면, IPFS와 결합될것이고 데이터가 저장되는 IPFS가 메시징 및 메모와 함께 활성화되면 IPFS해시도 자연스럽게 늘어남.

  ㅇ 태그(Tags)와 제한자산(Restricted Assets)
    - 개발자들의 논의에 앞서 태그제한자산에 대한 배경지식을 설명하겠다. 우선, 조건만 맞츠면 누구든지 레이븐 네트워크를 활용하여 자산을 등록하는 발급자가 될수 있지만 특정 자산의 소유권을 갖기위해서는 일정량의 레이븐과 등록하고자 하는 자산명, 그리고 태그적용이 필요하다. 가령, 일반 고유자산(제한자산 아님)을 생성하기 위해서는 500레이븐이 필요하고, 자산명은 중복되지 않는 독창적이어야한다. 그리고 제한자산(Restricted assets)을 생성하기 위해서는 1,500레이븐이 필요하고, 태그로 표현하면, $로 시작(예 : $ABC)하며, # 등 태그된 주소로만 전달이 가능하다. 향후 증권토큰 대비하여, 일반고유자산(예 : ABC)과 제한자산($ABC)를 서로 다른 주체가 보유하지 않고 하나의 주체가 보유하도록 설계하여 네이밍 측면에서 자산 소유권에 혼란을 방지하자는 것이다. 따라서, 누군가 제한자산을 구매등록하고싶으면 비(非)제한자산인 일반고유자산을 우선구매 등록하는 시스템을 구축될수도 있다. '일종의 패키지'인 셈이다.
    - (다시 개발자 회의로 돌아와서) Tron은 오로지 자산 발행자(issuer)만이 제한자산을 동결시킬수 있다고 말했고, 태그와 제한자산을 소각하는데 수수료가 든다고 말했다. 다만, 논리적 연산(and, or, not) 역할을 하는 태그의 경우 소각된다기 보다는 그 논리적 연산 역할을 못 하게 될것이라고 말했다. 어쨌든 태그를 없앨수 있는 사람은 그 태그와 관련된 토큰 발행자다.
    - 또한, 어느 누군가가 고유자산, 즉 비(非) 제한자산(예: BALL)을 갖고있는 경우에만 동일한 이름의 제한자산(예: $BALL)을 생성할수 있다고 말했다. 참고로 제한자산을 생성하는데 비용은 1500레이븐이다.

  ㅇ ASIC에 대하여
    - Tron은 (ASIC과 같은) 주문제작형 하드웨어 자체가 나쁘진 않지만 그런 장비는 중앙화를 야기한다고 말했다. 레이븐 개발자로써, 우리는 ASIC에 저항하는 입장을 갖고있으며, 따라서 ASIC 관련자들은 비밀리에 (레이븐을 채굴하기 위한) 계획을 짤 것이다.
    - 그러면서 Tron은 (채굴의 탈중앙 단계를 나열하면서) 1단계는 누구든지 컴퓨터 CPU로 레이븐을 채굴하는 것이고, 2단계는 일반적으로 사용하는 GPU로 채굴하는 것이고, 3단계는 GPU뿐만 아니라 FPGA까지 채굴에 가세하는 것이며, 4단계는 GPU와 FPGA, 그리고 약간의 ASIC채굴기가 진입하는 것이고, 마지막 5단계는 ASIC채굴기가 채굴을 장악하는 것이라고 말했다. Tron 본인이 볼때, 우리는 현재 3단계에 있으며, 혹자는 4단계에 진입했다고 말했다.
    - CPU채굴 중에서는 봇넷(컴퓨터 주인 몰래 그 컴퓨터를 사용하기 위해 심는 악성 소프트웨어)에 의한 사례들이 있지만 그것은 단지 개인차원의 문제일뿐 탈중앙성을 훼손시키지 않는 문제이기에 크게 신경쓰지 않서도 된다고 했다.
    - 또한, 특정 코인을 타킷으로 하는 ASIC을 제작하기 위해서는 상당한 연구개발과 예산이 투입되기 때문에, 약간의 알고리듬 변경으로도 ASIC제작 계획 자체를 무기력하게 만들수 있다고 말했다. 다만, 알고리듬 변경시 갑작스러운 변경은 GPU채굴자들에게 혼란을 주고 결국 네트워크 보안에도 영향을 끼칠수 있다고 말했다. 결국 최소한의 변경이 가장 좋지만, 많은 변경은 혼란을 가중하는 대신 아식 저항성을 높일수 있는 이점이 있다고 말했다.


□ 개인 논평

  ㅇ ASIC에 대한 레이븐 커뮤니티의 목소리
    - 지난 레이븐 회의 분석 및 논평 글에서 안내한 설문조사(https://www.surveymonkey.com/r/W29S96N) 결과가 나왔다. 레이븐 개발만큼 중요한 사안이기에 그 결과를 세부적으로 살펴보자.
    - 첫번째로, 레이븐 참여유형에 관해서다. 채굴자가 가장 많은 비중을 차지하고 있으며 근소한 차이로 보유자가 그 뒤를 따랐다. 투자자까지 감안한다면, 채굴자보다 비채굴자(보유자, 투자자)가 더 많다고 볼수 있다.

    - 두번째로, 채굴자에 한하여 몇개의 GPU로 레이븐을 채굴하는지에 대한 질문이다. 과반수가 12개 미만의 GPU로 채굴한다고 응답했고, 50개 이상의 GPU로 채굴한다는 사람들은 10%가 넘었다.

    - 세번째로, ASIC채굴에 대하여 찬성하는지에 대한 질문으로, 압도적으로 많은 응답자들이 ASIC채굴에 반대한다고 응답하였다.

    - 네번째로, 레이븐코인 체인이 분기되고 여러 체인으로 존재할 가능성이 있다해도 (ASIC 저항을 위해) 알고리듬을 변경할 가치가 있다고 보는가에 대한 질문이다. 서술식 응답으로 다양한 의견들이 나왔다. 우선 알고리듬 변경에 찬성하는 사람들은 이렇게 말했다. 애초에 레이븐을 지지한 이유가 평범한 개인들도 채굴이 가능하다는 점인데 ASIC채굴을 그냥 둬버리면 초기 지지자이자 대부분의 채굴자들을 저버리는 것이다. 그리고 개인 채굴자들을 떠나서, 처음부터 ASIC저항을 위해 여러개의 서브 알고리듬을 설계한 것인데, ASIC채굴을 그냥 내버려둔다면 레이븐 정체성을 잃는 것이다. 반면, 알고리듬 변경에 반대하는 사람들은 이렇게 말했다. ASIC을 저항하기 위해 알고리듬 변경을 해야하지만 수많은 체인으로 쪼개진다면 레이븐 프로젝트는 존폐의 길에 들어설것이다. 그리고 ASIC보다 중요한 것은 탈중앙성을 지키는 것이 아닌 네트워크 보안인데, 네트워크 보안이 붕괴되지 않는다면, 체인이 쪼개지는 것보다 ASIC채굴을 완화하는 방향을 지지할것이다.

    - 다섯번째로, ASIC채굴이 감지될경우, 어떤 전략을 세워야하는지에 대한 질문이다. 가장 많은 지지를 받은 전략은, 모네로의 전략처럼 채굴 알고리듬을 6개월마다 변경하는 전략이었다. 두번째로 많은 지지를 받은 전략은, 채굴 알고리듬을 즉시 바꾸는 전략이었고, 세번째로 많은 지지를 받은 전략은, 이더리움의 ProgPoW방식처럼 GPU에 특화된 알고리듬으로 완전히 바꾸자는 전략이었다.

    - 마지막 여섯번째로, ASIC채굴이 이미 진행중인지 묻는 질문이었다. 대부분 ASIC채굴이 진행중이지 않다는 답변을 한 가운데, 일부는 넷해시가 확 올랐다, 어떤 분석을 통해 ASIC이 있다고 믿고있다 등의 의견을 냈다.

  ㅇ 개인적인 ASIC에 대한 고찰
    - 필자는 모네로와 이더리움이 ASIC을 저항하기 위해 어떻게 대응했는지 지켜봤다. 레이븐에 대해서도, 레이븐 개발자 회의와 앞서 언급한 설문조사를 토대로 어떤 대응전략을 세울것인지 추측해봤다.
    - 우선, 코인 종류를 막론하고 최우선순위는 '네트워크의 보안'이다. ASIC저항이 아무리 중요해도 네트워크 생존만큼 중요할수가 없다. 그 네트워크 생존을 위해서, 모네로는 주기적으로 채굴 알고리듬을 변경하는 전략을 세웠고, 이더리움은 GPU에 특화된 알고리듬(ProgPoW) 도입을 검토중이지만 현재까지 이렇다할 전략을 세우지 않는 사실상의 '무전략'을 세우고 있다.
    - 현재 추이로 보면, 필자 생각에 레이븐은 '모네로 방식'을 따를 가능성이 좀 더 높으며 그 이유는 다음과 같다. 첫째, 트론을 포함한 개발자들이 모네로 전략을 주시하고 있기 때문이다. 둘째 레이븐은 태생적으로 강력한 ASIC 저항성을 갖도록 설계되어있는만큼 강력한 대응전략을 세울것이기 때문이다. 셋째, 최근 설문조사를 통해 커뮤니티의 여론도 알고리듬 변경을 대부분 원하고 있기 때문이다. 문제는 '본격적인 ASIC채굴 도입이 언제냐'인데, 제발 태그, 메시징, 제한자산, 투표 등 주요 기능들이 메인넷에서 활성화되고 난 이후에 ASIC을 대응하기만을 바랄뿐이다. 그때까지 개발자들과 커뮤니티가 ASIC저항에 대하여 통일된 입장을 내놓기를 바란다.


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

[Ethereum] '제64차 이더리움 개발자 회의' 분석 및 개인 논평(7월 5일) 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이 문제없이 출시되면 이더리움 네트워크와 커뮤니티가 새로운 도약을 함은 물론 투자자들에게도 기다림에 대한 충분한 보상이 있을거라고 여겨진다. 잠시 분석가 마인드를 내려놓고 투자자의 관점으로 볼때, 재작년의 이더리움 시세 폭등과 작년의 끝없는 이더 시세의 하락을 목격했던 바, 올해 말까지 시장은 이더리움을 어떻게 평가할지 사뭇 기대된다.


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

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

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