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

#73 Devs Meeting Review(25 Oct 2019)

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

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

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

  <Istanbul HF Roadmap>
   - May 17th (Friday): IstanbulHF EIP soft deadline
   - July 19th (Friday): EIP implementation for clients
   - October 30th (number): Ropsten Testnet HF
   - December : Mainnet HF(=Istanbul HF)

□ Istanbul HF 

  ㅇ When HF
    - Dano suggested that the date be December 4th or 11th, and Tim added that gives six weeks to get ready. Hudson said the fork block number should be set through Gitter Chat, noting again that we all agree on Dec 4th.

    - Piper said some unforeseen thing could causes us to want to push back the fork schedule and in that case it would be delayed by four weeks. Danno also said that the reason why a four-week period is needed is because all the clients need to put the block number into their code, and then all the exchanges and node operators need to download that code and install that code. So I think four weeks at a minimum is what we should budget for that, adding at least four weeks is necessary. Hudson said we're decided on December 4th, with January 8th as a backstop.

  ㅇ EIP-2124 : Software version identifier for nodes
    - karalabe first proposed EIP-2124 in May, a mechanism that makes it easy for ethereum clients to identify the software version of the node(computer server) in use, but the reason we brought it up again is that we had an issue with Rockstone where there was a miner pushing the non-forked chain quite a lot, adding clients have a hard time following a non-majority chain.

     - James said he knows the changes made by EIP-2124 do not require hard-forking, but asked if a process such as EIP proposal and execution is necessary, and Karalabe said yes, and Piper explained that clients can roll it out today if they want to, because all users don't have to agree and it doesn't affect the network.

   ㅇ EIP-centric system
    - Hudson expected Ice Age before the Berlin HF, post-Istanbul HF and asked how it works, and Karalabe, Piper and Martin said the Ice Age is just another EIP-centric thing that gets solved.

    - The following discussion focused on "Is the eIP-centered system's fork appropriate?" followed by opinions from various devs. Tim suggested that we could commit to upgrading in six months with whatever is ready then. However, Karalabe said it makes sense to bundle them together and added, We tried to do half year or eight month hard forks originally. Then, Pooja suggested that we can target for a biannual upgrade without fixed period just depending upon the readiness of EIPs, naming this model as ''hybrid of time-bound and EIP-bound'.

    - Martin asked if there were volunteers who wrote the EIP for the ice age delay and Hancock volunteered as the coordinator for the next fork.

    - Alex pointed out that on the EIP-centric system, each EIP champion is only interested in sharing the idea and then expecting client developers to finish it off. And Hudson said that what is essentially important is that we find ways to motivate ourselves more in the EIP-centric system, and pointed out that the reason why we are less interested in EIPs is because now we have more resources that are in the hybrid technical/non-technical range, so they expect more people to do it for others.

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 구현 마감기한
     - 10월 30일(수) : Ropsten Testnet HF
     - 12월 중 : Mainnet HF(=Istanbul HF)

□ 이스탄불 HF 

  ㅇ HF 시점 선정
    - Danno는 12월 4일 또는 11일로 선정하자고 했고, 이에 Tim은 앞으로 6주정도의 시간이 주어질거라고 첨언했다. Hudson은 12월 4일로 동의했음을 다시 언급하며 포크 블록넘버는 Gitter 채팅을 통해 정하자고 말했다.

    - Piper는 예기치못한 일로 인해 포크 일정을 늦출수 있고 그경우 4주정도 늦춰질거라고 말했다. Danno도 4주의 기간이 필요한 이유는 모든 클라리언트들이 포크블록넘버를 그들의 코드에 입력하고 모든 거래소와 노드운영자들은 코드를 받아서 설치해야하기 때문이라고 말하면서 일정이 늦춰진다면 최소 4주의 시간이 필요하다고 말했다. Hudson은 포크 시점을 12월 4일로 하고 유사시 연기시 포크시점을 1월 8일로 하자고 말했다.

  ㅇ EIP-2124 : 노드의 소프트웨어버전 식별 메커니즘
    - karalabe는 포크ID*가 지난 5월에 이더리움 클라이언트들이 사용 중인 노드(컴퓨터서버)의 소프트웨어 버전을 쉽게 식별할 수 있게 하는 메커니즘인 EIP-2124를 처음 제안했으나, 일반 클라이언트들은 대부분의 채굴자와 무관한 소외된 블록체인(non-majority chain)에 맞추기 위해 수기작업을 해야하는 어려움이 계속 존재하기때문에 다시 제안하는 바이다. 포크ID가 그런 어려움을 해소할수 있고, 이것은 작지만 결코 무시할 수 없는 변화다. 

    - James는 EIP-2124에 의한 변경은 하드포크가 필요없는 건 알지만 EIP 제안 및 실행과 같은 과정이 필요한지 물었고, karalabe는 그렇다고 말했고 Piper는 모든 사용자가 동의할 필요도 없고 네트워크에 영향을 끼치는 것이 아니기때문에 클라이언트는 원한다면 오늘이라도 실행할수 있다고 설명했다.

  ㅇ EIP중심 체제에 대하여
    - Hudson이 이스탄불HF이후에 있을 베를린HF이전에 있을 빙하기(채굴난이도상승)지연에 대한 예상을 물었고, karalabe, Piper, Martin은 빙하기 지연 건은 하나의 EIP로 하여 처리하면 된다고 말했다. 

    - 이에 논의의 무게중심은 'EIP중심체제의 포크가 적절한가'로 옮겨갔고 여러 개발자들의 의견이 이어졌다. Tim은 6개월이라는 기간을 우선 설정해놓고 그때까지 준비된 모든 EIP에 대해서 포크를 실행하자고 제안했다. 하지만 karalabe는 6개월간 한개 또는 두개의 EIP가 준비될 가능성이 있다면서 시간에 구애받지 않고 많은 EIP를 묶어서 6개월 간격이든 8개월 간격이든 포크를 해야한다고 반론했다. 이에 Pooja는 일년에 두번의 포크를 목표로 하되  EIP준비상황에 따라 포크시점을 정하는 하이브리드 방식을 제안했다. 

    - Martin은 빙하기 지연에 대한 EIP를 작성한 자원자가 있는지 물었고 Hancock이 자원하면서 차기 포크의 코디네이터가 되었다. 

    - Alex는 EIP중심체제 대하여 각 EIP책임자들이 그것에 대한 아이디어를 공유하는데 관심만 갖고 클라이언트 개발자들이 그것을 완료하는데 기대한다고 지적했다. 이에 Hudson은 본질적으로 중요한것은 우리가 EIP중심체제에서 더욱 동기부여할수 있는 방법을 찾는거라고 말하면서, EIP관련자들이 그것에 덜 관심갖게 된 이유는 더 많은 인적자원들이 있어서 이전보다 남들이 대신 해줄거라는 기대감이 더욱 커졌기 때문이라고 지적했다. 

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

댓글 쓰기

0 댓글