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

#68 Devs Meeting Review(16 Aug 2019)

- Related link : https://github.com/ethereum/pm/issues/119

English version(한국어 버전은 하단에)

□ Roadmap(https://eips.ethereum.org/EIPS/eip-1679) 

   <Istanbul HF Roadmap>
     - May 17(Fri): hard deadline to accept proposals for “Istanbul”
     - July 19(Fri): soft deadline for major client implementations
     - Aug 14(Wed): projected date for testnet network upgrade(Ropsten, Gorli, or ad-hoc testnet) Delayed due to EIP implementation and testing
     - Mid-September(Not fixed): Testnet fork
     - Oct 8 to 11: DevCon5, Osaka Japan
     - Oct 16(Wed) Initial projected date for mainnet upgrade(“Istanbul”)

□ Related to the EIPs for Istanbul HF

  ㅇIstanbulHF client update for EIPs allowed
    - (Nethermind) We only got EIP-1344, but didn't have EIP-152, 1108, 2028, 1884, 2200.
    - (Geth) We got EIP-1344, 1108, 2028, 1884, but didn't have EIP-152, 2200.
      * Other clients are absent.

  ㅇDecision about tentative EIPs
    - EIP-2200 and EIP-1884 will be included to Istanbul HF as they are judged to have reached an agreement without disagreement.

□ Conformance testing

  ㅇSpace for testing, Gitter channel and ReTestEth
    - EIPs to be included in HF must be tested, and the tests should be performed by EIP proposer or champion. However, sometimes proposers or champions are too motivated to know how to test what kind of test is required and in this case, other devs may suggest a way to facilitate the test. To do this, we will be able to test it through multiple clients on Gitter channel or ReTestEth.

□ Upgrading testnet and follow-up steps to Istanbul HF

  ㅇSeptember 4(Wed) of testnet HF block number 
    - We have just decided on the EIPs to be included in Istanbul HF but Parity is not present at the meeting, so we cannot decide testnet HF block number, which will be determined at next meeting (or through Gitter).
    - All clients should be prepared to execute all EIPs to be included in Istanbul HF by August 23(Fri) when the next meeting will be held.

  ㅇIstanbul HF conducted twice.
    - We will do Istanbul HF twice because there are EIPs we want but can't include in Istanbul HF such as EIP-1057 (or ProgPoW), but are not yet ready.

□ HF at once or separately

  ㅇAt once
    - By placing the prepared EIPs in the pool and implementing multiple EIPs at once, the plan can be established at the expected time intervals and there are chances for controling the HF issues.  However, EIPs proposers may be in a hurry due to the HF review deadline.

    - When fully prepared, EIP can be proposed and individual HF can be done. However, it will be messy as a number of seperate HFs are needed.

  ㅇ Fundamental issue
    - It is important to do HF at once or seperately, but a more important thing is that not much consideration is made until EIPs are implemented for HF. In fact, no one monitors the EIPs and no one pays attention at the last check. Therefore, clients should accept the proposed EIPs from the beginning, but attend the meeting to assess their progress.
    - Another concern is that before someone proposes an EIP and builds, and executes it, clients seem to know whether it's good or bad.
    - The problem with the EIP process is that the overall process cannot be tracked, and to solve it, the EIP progress is visually expressed so that many parties can know when to look at the EIP. To monitor progress from a client perspective, it is also good to use a dashboard.
    - Everything just discussed seems reasonable, and we don't have to decide immediately how to do it, but we'll discuss it further.

□ Naming HF

  ㅇ After Istanbul HF
    - Naming the HF was an old debate that began in April, and was re-discussed after two rounds of Istanbul HF. Second Istanbul HF is called by a different name besides Istanbul HF 2.
    - The HF after Istanbul HF will be named after the city where Devcon was held(e.g., Istanbul HF 2 will be Berlin HF where Devcon 0 was held).

※ Istanbul HF decision issue

    < Confirmed EIPs > Included in Istanbul HF, October 2019.
     1) EIP-152 (former EIP-2024) : Introducing a pre-compiled cotracts for EVM that implements a new encryption hashing algorithm called BLAKE2b.
     2) EIP-1108 : Proposal for reducing gas cost of alt_bn128 pre-compile. Improving personal information protection and scalability by reevaluating expensive elliptical curve calculation pre-comfiles.
     3) EIP-1344 : Specifying chain ID(a means to prevent replay of transactions between different chains), adding opcodes to access the chain ID to check the validity of signatures, and preventing other interchain replay attacks.
     4) EIP-1884: Maximizing block gas limit and stabilizing processing time by balancing gas consumption and resource consumption.
     5) EIP-2028 : Reducing gas cost of Calldata(where transaction data is stored when transaction is requested on the chain). Reducing Calladata costs can create potentially larger blocks, which can increase network latency, but can also have incidental effects of increased network security and scalability due to mathematical modeling and empirical estimation.
     6) EIP-2200(EIP-1283 + EIP-1706): Changing the total gas metering to reduce new usability for smart contract storage and excessive gas consumption when most methods of operation are not in place. In addition, SSTORE is not allowed if gas cost is lower than call stipend.

    < Tentatively decided EIPs > Included in 2020 HF
     1) EIP-663: Currently, SWAP and DUP commands are limited to the depth of 16 on the stack, but and corresponding SWAPn and DUPn are allowed access to all depths of 1024 items thanks to this EIP.
     2) EIP-1057 : It is called ProgPoW and is modified to make the most of commercial GPU resources in order to reduce ASIC's improved efficiency.
     3) EIP-1380: Reducing gas cost for self-calls, and reducing gas cost for call instructions when running a new instance of the currently loaded contracts.
     4) EIP-1702: For generalized account version management, enabling multiple versions of EVM to execute in the same block to facilitate HF while maintaining the correct function of the existing account.
     5) EIP-1962: Proposal to the definition and combination of elliptical arithmetic and runtime, an extension to EIP-1829 and lower working costs than the STATICCAL opcode in EIP-1109.
     6) EIP-1985: Applying the appropriate limit range for EVM parameters such as gas limit and block number. Explicit scope makes it easy to implement compatible clients.
     7) EIP-2045:improving the speed without introducing a separate subroutine and without changing the method of jump operation by reducing gas cost of computational opcode gas cost to increase Ethereum transaction volume(scalability).
     8) EIP-2046: Making file usage more efficient by reducing the gas of static calls to pre-com files.

□ Personal Comments

  ㅇEthereum's rate of issuance and return
    - In a personal comment to the 67th Ethereum Devs meeting, I explained about Ethereum 2.0. If you are an Ether investor, perhaps the most interesting thing in Ethereum 2.0 is the conversion of consensus protocols from PoW to PoS, especially funding deposits, validation, or staking.
    - But there is a thing associated with this stake, which is the issue rate. You will all know that adjusting the supply of one asset changes its value(assuming that other factors such as demand, are the same). However, it must also be known that network security and liquidity are very much related to such supply and value.
    - In order to learn more about these Ether monetary policies, we will look at the trend of Ether's issuance through photos below.
< the trend of ether issuance(orange) & volume(blue)(https://medium.com/ethhub) > 
  - Ether has shown rapid fluctuations in the issuance rate of major events such as difficulty bombs, major HFs, and the phase 2 of ethereum2.0(shard-chain). Such a trend in the rate of issuance is increasingly declining, and the total volume of issuance is rounded to a smooth curve. The most ideal aspect of the Ethereum network here would be the network's security with a lower issuance rate. However, if the issuance rate is to be low, there must be fewer validators to increase network security.
< ether issuance & staking rate in Ethereum2.0(https://docs.ethhub) >
    - In the picture above, a security risk is large because the lower the number of staked ether used for validation, the smaller the issuance rate, but the higher the chances that a few whales will control the network.
    - Of course, all of these analyses do not take into account the following variables: The first variable is the price of ether. As you know, the price volatility of cryptocurrency is very big, which can have a significant impact on the price-based staking rate. The second variable is the 'architectural factor of Ethereum 2.0. To date, it has been found that it is not possible to transfer ether between the chain and the existing PoW chain until phase 2(2020) of Ethereum2.0. In other words, when beconchain is introduced and validation is initiated in early 2020, if you migrate to a new version of ether and then stake it, the staked ether cannot be moved to the exchange or cashed until the shard-to-shade transmission is available in 2021(as is now known, you can transfer another validator). The third variable is "investment sentiment", which is a more fundamental variable than the aforementioned first and second variables and is about whether ether investors hold Ether. In other words, if ether's investment is strong, investors will not only hold but also stake ether, and if it is not strong, they will sell or invest in other coins.
    - I've talked about it in a complicated way, but it's simple. Keep an eye on ethereum, study and invest. To give you a simple hint for that, Devcon5 and IstanbulHF in October, Ethereum 2.0 Phase 0 and another HF in early 2020 are coming. What if ether is listed on BAKKT by the end of the year after Bitcoin?
   - But it's not only wishful thinking that these big events will bring about ether to the moon, but also keep in mind that each time it comes with enormous risks. Still, if our lives consist of a block of "decisions at moments" and a chain of "responsibilities for that decisions", I hope that your own blockchain will be a success project.

Disclaimer: Since this post was written for the purpose of providing information for investment, please be careful in your investment decision. You cannot copy, distribute, or edit the contents without my permission because it was made based on my own judgment based on the reference data.

한국어 버전

□ 로드맵(https://eips.ethereum.org/EIPS/eip-1679

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

□ 이스탄불HF 관련 EIP 관련

  ㅇ 이스탄불HF 허용(+잠정보류) EIP에 대한 클라이언트 업데이트
    - (Nethermind) 우리는 EIP-1344만 실행하였고, EIP-152, 1108, 2028, 1884, 2200은 아직 실행하지 않았습니다.
    - (Geth) EIP-1344, 1108, 2028, 1884를 실행하였고, EIP-152, 2200은 아직 실행하지 않았습니다.
      * 그 외 클라이언트는 불출석 등으로 언급이 되지 않았음

  ㅇ 잠정보류된 EIP에 대한 결정
    - EIP-2200과 EIP-1884은 이견없는 합의가 이루어졌다고 판단되므로 이스탄불HF에 허용될 예정이다.

□ 적합성 테스트

  ㅇ 테스트를 위한 공간, Gitter channel과 ReTestEth
    - HF에 포함될 EIP는 테스트가 반드시 행해져야하며, 그 테스트는 EIP제안자나 담당자가 수행하여야 한다. 다만, 제안자나 담당자가 의욕이 넘쳐도 어떤 테스트가 필요하는지 어떻게 그 테스트를 할수 있는지 모를때가 있는데, 이럴경우에는 다른 개발자들이 그 테스트를 용이하게 할 방법을 제시할수 있다. 이를 위해서 Gitter channel이나 ReTestEth와 같은 것을 통해 테스트를 하면 여러 클라이언트를 통해 테스트를 할수 있을것이다.

□ 테스트넷 업그레이드 및 이스탄불HF 후속 단계

  ㅇ 9월 4일(수) 테스트넷HF의 블록넘버 
    - 이제 막 이스탄불HF에 포함될 EIP를 정했고 Parity측이 회의에 참석하지 않은 관계로 우리는 테스트넷HF 블록넘버를 정할수 없으며, 그 블록넘버는 다음 개발자 회의에(또는 Gitter를 통해) 결정될것이다.
    - 이에 모든 클라이언트들은 다음 개발자 회의가 열리는 8월 23일(금)까지 이스탄불HF에 포함될 모든 EIP를 실행할수 있도록 준비하기를 바란다.

  ㅇ 이스탄불HF를 두번에 걸쳐 실시
    - 우리는 EIP-1057(또는 ProgPoW)와 같이 이스탄불HF에 포함시키고 싶지만 아직 준비가 되지 않은 EIP가 있기때문에 이스탄불HF를 부득이하게 두번에 걸쳐 실시할 예정이다.

□ HF를 모아서 할것인가 여러개로 나눠서 할것인가

  ㅇ 모아서 HF하기
    - HF가 준비된 EIP를 풀에 대기시켜 여러 EIP를 한번에 구현함으로써 예상가능한 시간간격대로 계획을 수립할수 있으며 HF와 관련된 사안들을 더욱 컨트롤할수 있는 여지가 있다. 다만 HF 검토 기한에 쫓겨 EIP담당자들이 다소 서두를수 있다.

  ㅇ 나눠서 HF하기
    - 충분히 준비가 되었을때 EIP를 제안하고 개별HF를 추진할수 있다. 다만, 수많은 개별HF를 추진해야하므로 그 과정에서 혼선이 발생할수 있다.

  ㅇ 근본적인 문제 
    - 모아서 또는 나눠서 HF를 하는것도 중요하지만, 더 중요한 문제는 EIP가 HF로 구현될때까지 많은 검토가 이루어지지 않는다는 점이다. 실제로 아무도 EIP를 모니터링하지 않으며 마지막 점검시 아무도 주의를 기울이지 않는다는 것이다. 따라서 클라이언트들은 초반부터 제안된EIP를 받아들이되 회의에 참석하여 그 EIP진행여부를 따져봐야한다.
    - 또다른 걱정거리는 누군가 EIP를 제안하고 그것에 대해 구축, 실행, 실행하기도 전에 클라이언트들로 하여금 그게 좋은건지 나쁜건지 파악해달라는 듯 하는 태도다.
    - EIP 프로세스의 문제점은 전체적인 프로세스를 추적할수 없다는 점이며, 그것을 타개하기 위하여 EIP진행상황을 시각적으로 표현하여 많은 당사자가 언제 EIP를 살펴봐야하는지 알수있게 하는 것이다. 클라이언트 관점에서 진행상황을 모니터링하기 위해서는 대시보드를 활용하는 것도 좋다.
    - 방금 논의된 것들은 모두 합리적으로 보이며, 어떻게 해야하는지 당장 결정할 필요는 없지만 더 논의하기로 한다.

□ HF 이름 짓기

  ㅇ 이스탄불HF 이후의 HF
    - HF 이름을 지어내는것은 지난 4월부터 시작된 오래된 토론 안건으로, 이스탄불HF가 두 차례에 걸쳐 실시되어 다시 논의하게 되었다. 2번째 이스탄불HF는 이스탄불HF 2 외에 다른 이름으로 불리는게 어떤가.
    - 이스탄불HF이후의 HF는 데브콘이 열린 도시의 이름을 따서 명명하기로 한다(가령 이스탄불HF 2는 데브콘0이 개최된 베를린HF로 하는식)

  ※ 이스탄불HF 결정 사안

    < 확정 EIPs > 2019년 10월 이스탄불HF에 반영 
     1) EIP-152(前 EIP-2024) : BLAKE2b라는 새로운 암호화 해싱 알고리듬을 구현하는 사전컴파일 컨트렉트를 EVM에 도입.
     2) EIP-1108 : alt_bn128 프리컴파일 가스비 절감제안. 값비싼 타원곡선산술 사전컴파일을 재평가하여 개인정보보호와 확장성을 개선.
     3) EIP-1344 : 컴파일링시 체인ID(서로 다른 체인간 트랜잭션 재생을 방지하는 수단)를 지정하고 opcode를 추가하여 그 체인ID에 접근하여 서명의 유효성을 검사하며, 다른 체인간 리플레이 어택 등을 방지.
     4) EIP-1884 : 가스소비와 자원소비 간 균형을 맟추어 블록가스제한을 극대화하고 처리시간이 안정화.
     5) EIP-2028 : Calldata(이더리움 상에서 트랜잭션 요청시 전송 데이터가 저장되는 곳)의 가스비를 현행보다 감소. Calladata비용이 절감되면 잠재적으로 더 큰 블록이 생겨 네트워크 지연이 증가하지만, 수학적 모델링과 경험적 추정에 의해 네트워크 보안이 강해지고 확장성이 증가되는 부수적인 효과가 있을수도 있음.
     6) EIP-2200(EIP-1283 + EIP-1706) : 총 가스 계량기(Net gas metering)를 변경하여 스마트컨트렉트 저장소를 위한 새로운 활용가능성과 대부분의 작동방식이 맞지 않을때 발생하는 과도한 가스비를 감소. 또한, 가스비가 집행비(Call stipend)보다 낮은경우 SSTORE사용을 불허함.

    < 잠정보류 EIPs > 2020년 차기HF에 반영
     1) EIP-663 : 현재 SWAP과 DUP명령어는 스택상 16의 깊이로 한정되어있는데, 이들과 대응되는 SWAPn과 DUPn을 1024개의 아이템의 모든 깊이까지 접근을 허용한다.
     2) EIP-1057 : ProgPoW로 불리며, ASIC의 향상된 효율성을 반감시키위하여, 상용GPU자원을 최대한 활용되도록 수정.
     3) EIP-1380 : 자기호출에 대한 가스비 절감으로, 현재 로드된 컨트렌트의 새 인스턴스를 실행시 호출지시에 대한 가스비를 절감.
     4) EIP-1702 : 일반화된 계정버전 관리를 위한 것으로, EVM의 여러버전을 동일한 블록에서 실행할 수있게하여 기존 계정의 정확한 기능을 유지하면서도 HF를 용이하게 함.
     5) EIP-1962 : 타원 산술 및 런타임 정의와 결합에 대한 개선안으로, EIP-1829에 대한 확장안이며 EIP-1109에서의 SATICCAL opcode보다 작업비용이 더 저렴.
     6) EIP-1985 : 가스제한, 블록넘버 등 EVM 매개변수들에 대한 적정 한계범위를 적용한다. 명시적인 범위를 적용하면 호환가능한 클라이언트를 구현하는데 용이함.
     7) EIP-2045 : 이더리움 거래량(확장성)을 높이기 위하여 Computational opcode의 가스비를 줄여서 별도의 서브루틴 도입없이 또 점프작동방식을 변경없이 속도를 향상함.
     8) EIP-2046 : 프리컴파일에 대한 정적호출의 가스비를 줄임으로서, 파일사용이 보다 효율적.

□ 개인 논평

  ㅇ 이더리움 발행률과 수익률
    - 지난 67차 이더리움 개발자 회의의 개인 논평에서 필자는 이더리움2.0에 대하여 설명하였다. 만약 당신이 이더 투자자라면 이더리움2.0에서 가장 관심있는 사안은 아마도 PoW에서 PoS로의 합의프로토콜 전환일것이고, 그중에서도 자금 예치 및 유효성 검증, 즉 스테이킹에 대한 관심이 클 것이다.
    - 그런데 이 스테이킹과 연관된 요인이 있으니 바로 '발행률'이다. 한 자산의 공급을 조절하면 (수요 등 다른 요인은 동일하다는 전제하에) 그에 따른 가치가 변한다는 것은 다 알것이다. 다만 네트워크에서는 그런 공급과 가치에 따라 네트워크 보안과 유동성에도 매우 큰 관련이 있다는 점도 반드시 알아야 한다.
    - 이러한 이더의 통화정책을 좀 더 알아보기위하여 이더의 발행 추이를 사진을 통해 알아보겠다.
< 이더 발행률(주황색)과 발행량(파랑색)의 추이(https://medium.com/ethhub) >

    - 이더는 난이도 폭탄, 주요HF, 이더리움2.0의 2단계(샤드체인도입) 등 굵직굵직한 이벤트마다 급격한 발행률 변동을 보이고 있다. 그런 발행률 추세는 점점 더 발행이 줄어드는 추세를 보이고 있으며, 그럴때마다 총 발행량은 원만한 곡선을 보이고 있다. 여기서 이더리움 네트워크의 가장 이상적인 모습은, 보다 낮은 발행률을 보이면서도 네트워크 보안성을 높은 상태일것이다. 그런데 발행률이 낮으려면 그만큼 유효성 검증자가 적어야하는데, 네트워크 보안성이 높아지려면 유효성 검증자가 많아야한다.

< 이더리움2.0에서의 이더발행과 스테이킹이율(https://docs.ethhub.io) >

    - 바로 위의 사진에서 보면, 유효성 검증에 활용되는, 즉 스테이킹된 이더가 적을수록 발행률은 작지만 소수의 고래들이 네트워크를 컨트롤할 확률이 높아지기에 보안리스크는 크다고 볼 수 있다.
    - 물론 이 모든 분석이 다음과 같은 변수들은 고려하지 않은 것이다. 첫째 변수는 '이더의 가격'이다. 아시다시피 암호화폐의 가격 변동성은 매우 큰 편으로 가격에 따른 스테이킹비율에도 적지 않은 영향이 있을수 있다. 둘째 변수는 '이더리움2.0의 구조적 요인'이다. 현재까지 밝혀진바로는, 이더리움2.0의 0단계(2020년 초)에서 2단계(2021년)까지는 체인안팎, 즉 기존PoW체인과 비콘체인 간 이더의 쌍방향 전송이 불가하다. 다시 말해, 2020년 초에 비콘체인이 도입되어 유효성 검증이 개시될때, 당신이 새로운 버전의 이더로 마이그레이션 후 스테이킹 할 경우 그 스테이킹한 이더는 2021년 샤드간 전송이 가능할때까지 거래소로 옮길수도 현금화 시킬수 없다(현재까지 알려진 바로는 다른 검증자에게 전송가능하다). 셋째 변수는 '투자자 심리'다. 앞서 말한 첫째, 둘째 변수보다 더욱 근본적인 변수로, 이더 투자자가 이더를 갖고있을것인가에 대한 사안이다. 즉, 이더의 투자성이 크다고 하면 홀딩은 물론 스테이킹까지 할것이며 투자성이 적다고 하면 이더 발행률과 수익률과는 무관한 현금화, 타 코인 투자 등을 선택할것이다.
    - 뭐 복잡하게 얘기했지만, 간단하다. 주시하고 공부하고 투자하라. 그것을 위하여 간단명료한 힌트를 드리자면, 10월에 있을 Devcon5이스탄불HF, 2020년 초에 있을 이더리움2.0 0단계또다른 HF가 우리를 기다리고 있다. 혹시 아나, 비트코인 다음으로 이더리움이 BAKKT에 연내 상장될지(이 글이 성지가 되길).
    - 하지만 이런 큰 이벤트들이 이더의 떡상을 부른다는 것은 희망사항일뿐, 그때마다 엄청난 리스크가 동반된다는 사실도 명심하길 바란다. 그럼에도, 우리의 인생이 '매순간의 결정이라는 블록''그 결정에 따른 책임이라는 체인'으로 구성되어있다고 한다면, 당신만의 그 '블록체인'이 꼭 성공하는 프로젝트가 되길 바라면서 이번 논평을 마치겠다.

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

 1) https://medium.com/ethhub/the-basics-of-ethereum-2-0-economics-3bd2ffc7fd0e
 2) https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-economics

댓글 쓰기

0 댓글