[Ethereum] '제69차 이더리움 개발자 회의' 분석 및 개인 논평(8월 23일) // #69 Devs Meeting Review(23 Aug 2019) v1.0

#69 Devs Meeting Review(23 Aug 2019)

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



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

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

   <Istanbul HF Roadmap>
     - May 17(Fri): Istanbul HF EIP soft deadline
     - July 19(Fri): EIP implementation deadline for clients
     - Mid-September(Not fixed): Testnet HF
     - October 16(Wed) Mainnet HF(=Istanbul HF) *May be delayed.


□ Istanbul HF-related client update

  ㅇ Whether to merge Istanbu lHF-related EIP by clients
    - (Pantheon) All EIPs have been merged and merge status by EIP/Client has been created here.
    - (Geth) All EIPs have been merged and implemented.
    - (Aleth) EIP-1108, 1344, 2028 have been merged, but EIP-1884, 2200 is still open.
    - (Parity) EIP-2028 is merged, EIP-1344, 2200 is open but has not yet been implemented, and EIP-1108 is closed.
    - (Trinity) EIP-1108, 2200 have been merged, and EIP-1344, 1884, 2028 are open.
    - (Nethermind) All but one EIP have been merged and will soon be merged.


□ Istanbul Testnet HF Block Number Decision

  ㅇClient updates and mainnet HF schedule
    - Since not all clients, including Parity, have yet to complete the merging and implementation of all EIPs,  it is not immediately possible to determine the Testnet HF block number, so it is necessary to have a devs meeting  next week or decide via gitter. That way we can discuss how much more time we need, or reevaluate (on EIP, etc.).

    - If we discuss the testnet HF block number again at the end of August, it will be mid-September when Parity is ready and mainnet HF scheduled for October may not be available.

    - There is one issue related to Testnet HF and Mainnet HF, and if this is not resolved, it is necessary to mention it because it may delay Mainnet HF. As of the cost of gas, it may be necessary to raise the cost of gas to prevent some contracts from being interrupted. In fact, Martin concluded that it could potentially occur. According to his analysis, in some cases, gas charges can soar or fixed gas costs are consumed for a call. However, there is no permanent solution to this problem, so once HF hapens, we can find a solution based on the case that contracts actually stop.

    - But the problems is that contracts would be stopped and not be implemented properly, and then something like Parity multisig incident could happen, and there may be no chance to modify or add function in the future.

    - But as for the gas price fluctuations, so far no one has ever thought it would be a problem and no one has fixed it. We can upgrade to solve the gas problem, but then we can have a completely different kind of problem. We have to work it out before we set testnet HF block number, but in order to have a criteria, we have to make a formal proposal like EIP, which should be a less likely to be hacked or more certain way to proceed. Only then can the debate be led to a technical level and how best to deal with such concerns. That's what it means. It's the kind of community that's worried about it. In that sense, we need to listen to the participants who have such concerns in the community and think more about whether we need to find a clear solution before testnet HF.


□ Decision issues on previous devs meeting

  ㅇ Clients and EIPs
    - All clients have decided that all EIPs for Istanbul HF should be implemented by August 23, but this has been delayed to September 6, so we will not set a testnet HF block number right now.

  ㅇ Mainnet HF Schedule
    - Although it is still difficult to determine, Mainnet HF schedulemay be postponed to November, given that it should take at least a month from testnet HF.

※ 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

  ㅇInform the Ethereian
    - As mentioned in the meeting, the Istanbul HF is likely to be postponed following the last Constantinople HF. Some may be very disappointed by the news, and community like Reddit complaind about it. There are concerns and criticisms that Parity (21%), which is the second most important client of Ethereum, is still not even merging EIP, rather than implementing it. In February, I wrote and shared the article "2019 Etherium Selection, Splited or Growing"(click here). The point of the article is that they often show a mysterious way of contributing to Ethereum, whether it's an alliance or enemy.

    - Anyway, this trip to Istanbul will be delayed a little bit. In fact, such delays may be considered good or bad from the perspective of devs, investors, and so on, but there is no great dissatisfaction with the delay in itself. Because I do know why it is being postponed. Even at this meeting, a dev raised questions about gas charges (simple verbal offers to raise related gas charges so that some calls could be interrupted), and there was a long discussion on whether to include this into testnet fork, and if the issue was an official proposal, such as EIP, and there was enough time to review and verify it, then testnet HF would have been delayed further.

    - In short, dev, especially core devs, think that it is better to postpone it to prevent accidents such as Constantinople Fork and Parity Multisig incident in the past, and I agree with that attitude.

    - As an analyst, Ethereum will wait and see to invest from the viewpoint of institutional investors who are extremely conservative in their investments, and it is not the time for us to invest either. In the course of time, Ethereum has become so big that it will take a lot of review, verification and time to easily change the arrangement, so often there will be long discussions, delays, and alternatives.

    - But as an investor, Ethereum is still attractive. Thanks to the steady research and development of Buterin and Vlad, who advocated the possibility of PoS, the time is slowly approaching to show the real face of Ethereum. There are already too many allies and foes for Ethereum's color to die. In other words, there is so much interest of it. If EEA(Enterprise Ethereum Alliance) and Deapps are successful, Ethereum will thrive, and even if Ethereum Killers such as EOS suceed, it wouldn't be not so bad for Ethereum.

  ㅇInform the blockchainer
    - The greatest redistribution we will experience in the near future, thanks to the so-called Blockchain Revolution, will be the Redistribution of value, not the Redistribution of wealth. Wealth depends on how much money we have, but value depends on where and how we participate. That doesn't mean there will be a world where the rich suddenly become beggars and the poor become rich forever, but if the blockchain becomes popular, there will be a world where assets can be distributed in a more transparent and fair manner than the existing one.

    - So if someone says that cryptocurrency is expensive and useless, just say that the greatest redistribution, or redistribution of value, has already been shown by Bitcoin and Ethereum. I hope that all blockchain and cryptocurrency projects, including any other ethereum, will be developed

without losing their vision and initial focus, and that there will be good results as community participants have paid attention and invested in them.


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일(금) : 주요 클라이언트의 EIP 구현 마감기한
     - 09월 중순(미정) : 테스트넷HF
     - 10월 16일(수) 메인넷HF(=이스탄불 HF) *지연될수도 있음

□ 이스탄불HF 관련 클라이언트 업데이트

  ㅇ 클라이언트별 이스탄불HF 관련 EIP 병합 여부
    - (Pantheon) 모든 EIP를 병합하였고, EIP별/클라이언트별 병합 현황 사이트를 만들어봤다.https://notes.ethereum.org/@holiman/SyT_rGjNr
    - (Geth) 모든 EIP를 병합하였고 구현하였다.
    - (Aleth) EIP-1108, 1344, 2028는 병합하였으나, EIP-1884, 2200은 아직 열려있다.
    - (Parity) EIP-2028은 병합, EIP-1344, 2200은 열려있으며 아직 구현되지 않았으며 EIP-1108은 닫혀있다.
    - (Trinity) EIP-1108, 2200은 병합되었고, EIP-1344, 1884, 2028은 열려있다.
    - (Nethermind) 하나의 EIP를 제외하고 모두 병합하였으며, 곧 모두 병합할 것이다.


□ 이스탄불 테스트넷 HF 블록넘버 결정

  ㅇ 클라이언트 업데이트와 메인넷HF 일정
    - Parity를 비롯하여 아직 모든 클라이언트가 모든 EIP의 병합 및 실행을 완료하지 않았기 때문에 당장 테스트넷HF 블록넘버를 결정할수 없으며, 따라서 다음주에 개발자 회의를 개최하거나 gitter를 통해 결정해야한다. 그렇게 해야 우리가 얼마나 많은 시간이 더 필요한지에 대해 논의하거나, (EIP 등에 대하여) 재평가를 할수 있을 것이다.
    - 그렇게 8월말에 다시 테스트넷HF 블록넘버를 논의한다면, Parity가 준비되었을때는 9월 중순이 될것이며 10월에 예정되어있는 메인넷HF가 불가능할수도 있다.
    - 테스트넷HF와 메인넷HF와 관련된 사안이 하나 있는데, 이것이 해결되지 않으면 메인넷HF를 지연할 수 있기 때문에 언급할 필요가 있다. 가스비와 관련된 것으로, 일부 컨트렉트가 중단되지 않도록 가스비를 올려야할수도 있다. 실제로 그럴 가능성에 대한 분석은 개발자 Martin에 의해 수행되었으며, 잠재적으로 발생할수 있다는 분석 결론이 있었다. 분석에 따르면, 어떤 경우에 특정 호출에 대하여 가스비가 치솟을때도 있고 고정된 가스비가 소비될때도 있다. 하지만 이런 문제를 영원히 해결할수 있는 해결책은 없으므로, 일단 이대로 HF를 추진하되 실제로 컨트렉이 중단된 경우를 바탕으로 해결책을 찾을수도 있다.
    - 하지만 정말 걱정되는건 잠재적인 문제로 인하여 컨트렉이 중단되어 제대로 이행되지 않았는데, 그걸 (강제로) 풀다가 과거의 Parity Multisig와 같은 사태가 발생할수 있으며, 그렇게 된다면 앞으로 수정하거나 기능을 추가할 기회가 없을수도 있다.
    - 다만 우리가 지금 말하고 있는 가스비 변동에 대해서는, 여태껏 누구든지 이것이 문제가 될거라고 생각하지 않았고 따라서 아무도 그것을 고치지 않았다. 가스비 문제 해결을 위해 업그레이드를 할수도 있지만 그 다음에는 완전 다른 종류의 문제가 발생할수도 있다. 테스트넷HF 블록넘버를 정하기 전에 해결해야 하지만 기준을 갖기 위해서 EIP와 같은 공식적인 제안서를 작성해야하며, 그것은 해킹될 여지가 덜 하거나 더 확실한 방법이어야 합니다. 그렇게 해야만 기술적인 수준으로 논의가 이어질수 있고, 그런 고민을 어떻게 최선의 방법으로 다룰수 있는지 알수 있을것이다. 그런의미에서 커뮤니티안에서 그런 고민을 갖고 있는
참여자들에게 귀 기울여야하며 테스트넷HF 이전에 확실한 해결책을 찾아야하는지에 대해서는 좀 더 생각해볼 필요가 있다.


□ 이전 개발자 회의 결정 사안

  ㅇ 클라이언트의 EIP
    - 모든 클라이언트가 8월 23일까지 이스탄불HF에 대한 EIP를 모두 구현해야한다고 정하였지만 이는 9월 6일로 지연되었으며, 따라서 테스트넷HF 블록넘버는 정하지 않겠다.

  ㅇ 메인넷 HF 일정
    - 아직 단정짓긴 어렵지만, 테스트넷HF 일정이 정해진 이후에 메인넷HF 연기를 비롯한 일정을 정할 수 있을것이며 테스트넷HF로부터 최소한 한달 이상의 시간을 가져야한다고 볼때 11월로 연기될수도 있다.


  ※ 이스탄불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에서의 STATICCAL opcode보다 작업비용이 더 저렴.
     6) EIP-1985 : 가스제한, 블록넘버 등 EVM 매개변수들에 대한 적정 한계범위를 적용한다. 명시적인 범위를 적용하면 호환가능한 클라이언트를 구현하는데 용이함.
     7) EIP-2045 : 이더리움 거래량(확장성)을 높이기 위하여 Computational opcode의 가스비를 줄여서 별도의 서브루틴 도입없이 또 점프작동방식을 변경없이 속도를 향상함.
     8) EIP-2046 : 프리컴파일에 대한 정적호출의 가스비를 줄임으로서, 파일사용이 보다 효율적.


□ 개인 논평

  ㅇ 이더리안에게 고(告) 함
    - 이번 회의에서 언급되었듯이, 지난 콘스탄티노플HF에 이어 이번 이스탄불HF도 연기될 가능성이 높아졌다. 이 소식에 매우 아쉬워하는 이도 있겠지만, 그 연기의 이유에 대해서 레딧 등 해외 이더리안들에 대한 성토가 이어지고 있다. 이더리움 클라이언트 중에서 Geth(76%) 다음으로 비중이 높은 Parity(21%)가 여전히 이스탄불HF 반영 확정 EIP를 구현은 커녕 병합조차 하고 있지 않는 상태에 대한 우려와 비판이 있다. 필자는 지난 2월 '2019 이더리움의 선택, 분열인가 성장인가'(여기 클릭)이라는 글을 작성하여 공유한적이 있다. 해당 글과 이번 논평 일부를 차지하고 있는 Parity에 대한 요지는 이들이 이더리움에 기여한 바는 크나 종종 아군인지 적군인지 알수없는 행태를 보인다는 점이다. 여기서 더 나아가면 오해의 소지가 있을까봐 함구하겠지만 신경이 쓰이는 건 어쩔수 없다.
    - 여튼 이번 이스탄불로 가는 여정은 조금 미뤄질것 같다. 사실, 하드포크(네트워크 업그레이드) 등이 연기되는 것은, 개발자, 투자자 등 관점에 따라서 좋게 또는 나쁘게 볼수 있겠지만, 개인적으로 연기되는 그 자체는 큰 불만이 없다. 왜냐면 연기되는 이유를 알기때문이다. 이번 회의의 경우에도, 한 개발자가 가스비에 대한 의문을 제기(일부 호출에 대해 컨트렉이 중단될수 있으므로, 그런 사태가 일어나지 않도록 관련 가스비를 올리자는 단순 구두상 제안)하였고 이걸 테스트넷 포크부터 고민하여 반영하냐 안하냐에 대한 긴 논의가 있었으며, 이 사안이 만약 EIP 등 공식적인 제안이었고 검토 및 검증할 시간이 충분했다면 테스트넷HF가 더욱 미뤄졌을것이다.
    - 간단히 말해, 개발자, 특히 코어 개발자 입장에서는 어설프게 준비하다가 과거 콘스탄티노플 포크때나 패리티 멀티시그 사태 같은 사고가 날 바에야 연기하는게 낫다고 생각하고 필자 역시 그 점에는 공감하고 있다.
    - 분석가로써 볼때, 이더리움은 투자에 지극히 보수적인 성향을 가진 기관투자자 입장에서는 관망할 것이며, 필자 역시 냅다 지를 타이밍은 아니라는 입장이다. 그간 이더리움이 성장하는 과정에서 그것이 보여준 혁신만큼이나 너무 커버려 합의방식 등을 쉽게 바꾸기에는 많은 검토, 검증, 시간이 필요할 것이며, 그래서 종종 긴 논의와 연기, 대안 등이 나타는 것이다.
    - 그런데 투자자로서 볼때, 이더리움은 여전히 매력적이다. 일찌기 지분증명방식(PoS)의 가능성을 주창한 부테린 군과 블라드 등의 꾸준한 연구와 개발 덕분에 이더리움의 진면모를 보여줄 시기가 서서히 도래하고 있다. 이더리움의 색깔이 빛바래기에는 이미 너무 많은 아군과 적군이 있다. 달리말하면 그만큼 관심이 크다는 뜻이다. EEA(Enterprise Ethereum Alliance), 디앱(dApps) 등 아군들이 흥할수록 이더리움은 더욱 번성할거고, EOS 등 이더리움 킬러 등이 성공해도 모티브가 이더리움인만큼 이더리움에 결코 백프로 마이너스는 아닐것이다.

  ㅇ 블록체이너에게 고(告) 함
    - 우리가 소위 말하는 ‘블록체인혁명’ 덕분에 가까운 미래에 경험할 최고의 재분배는 '부의 재분배(Redistribution of wealth)'가 아닌 '가치의 재분배(Redistribution of value)'일 것이다. 부는 우리가 돈을 얼마나 갖고 있느냐에 달려있지만 가치는 우리가 얼마나 어디에 참여했는지에 달려있습니다. 그렇다고 부자들이 한순간 거지가 되고, 빈자들이 떼부자가 되는 세상이 오는 것은 아니지만, 블록체인이 대중화된다면 가치를 담는 유무형 자산들이 기존 세상보다 더욱 투명하고 공정한 방식으로 분배될 수 있는 세상이 온다는 말이다.
    - 따라서 누군가 암호화폐를 비싸기만 하고 쓸모없다고 말하거든, 그런 최고의 재분배, 즉 가치의 재분배의 가능성을 비트코인이더리움이 그만의 철학으로 이미 보여줬다고 답하면 된다(그래도 못 알아들으면 측은지심의 눈빛을 발산하길 바란다). 아무쪼록 이더리움을 포함한 모든 블록체인과 암호화폐 프로젝트가 비전과 초심을 잃지 않고 개발했으면 좋겠고 커뮤니티 참여자도 관심갖고 투자한 만큼 좋은 결과가 있기를 바란다.


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

댓글 없음:

댓글 쓰기

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

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