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

#72 Devs Meeting Review(4 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 (Fri): IstanbulHF EIP soft deadline
   - July 19th (Fri): EIP implementation for clients
   - October 2nd (Wed): Ropsten Testnet HF
   - November : Mainnet HF(=Istanbul HF)

□ Ropsten Fork
  ㅇ What really happened then?
    - Robsten fork occurred two days earlier than the expected date of October 2. Someone was mining with about 1.5 giga hashes and the miner was pushing the existing chain. Now that the miner continues the non-Istanbul chain, which has caused Ropsten network to become unstable and many of the nodes are non-Instanbul nodes, we have been figuring out what is going on in the network.

    - Although Geth client users filter the non-Istanbul chain, Parity client users are not sure. In fact, we have several options to prevent this situation in the future. But in Ropsten's case, it's too late to add a correction.

    - Devs issued some problems the last time they worked at Ropsten, but no one contacted them. However, although they thought it was a good test for chain handling before, the devs were not happy. Nevertheless, it is very interesting to watch how clients behave in order to continue the longer chain.

    - Ropsten crisis has happened anyway, but there is no big concern at mainnet because it doesn't see much chance of the Istanbul chain being pushed out by the giant miners.

□ Ethereum Roadmap 2020: Community discussion (Debcon5)
  ㅇ Ethereum Community Debate at Devcon5
    - On the first day of Devcon 5, there will be sessions to discuss roadmap for Ethereum1.0, 1.x and 2.0. If you are interested, please join us and discuss it with our key devs.

 < Community Debate Overview >
  ㅇ When : October 8, 2019 (1-5 p.m.)
  ㅇ Where: Convention room (200 seats or more)
  ㅇ What : Discussion organized by the Ethereum Magicians for those who contributed to Ethereum1.0 and Ethereum2.0
   ※ Click here for more information 

□ Ice Age
  ㅇ Time to release the ice age
    - The Ice Age EIP will not be included in Istanbul Falk because it has no specific cause. Now Istanbul is defined and Ropsten fork has occurred, so it is impossible to apply the ice age. Also, according to the calculations of some developers, the ice age should be taken enough time to apply to another fork rather than to include it in Istanbul.

□ Testing updates
  ㅇ Fork ID definition
    - Anyone who has an objection to the Geth team, which defines Eth64 as a fork ID* and wants to roll out, will challenge AllCoreDevs within two weeks.
    *ForkID : A unique identifier of the block chain, created to distinguish it from the unique identifier(ID) of the existing main chain at fork time. If the fork ID is newly defined, problems such as replay attack can be prevented before long.

  ※ Confirmed EIPs for Istanbul HF
    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. 

□ Personal comments
  ㅇ Fork and job verification method
    - Ropsten, one of Istanbul testnets, had a fork earlier than expected because it was mined as quickly. In other words, the time spent verifying the block has been reduced than usual. As is well known, when a fork occurs, it is important for the miner's will and cooperation to be as important as the miner's new version must be upgraded directly to match the fork.

    - But in the case of Ropsten fork, the network became unstable, with a huge hash dominator running an existing chain rather than a fork chain and confused about what version of the chain nodes should follow, where non-minor ether holders only have ether in their wallets as safe as possible and nothing can be done. This is the characteristic and disadvantage of proof of work(PoW). If ether was based on proof os staking(PoS), it is granted distributed authority to contribute to the maintenance of the direct network by depositing the principal Eider as a valid stake and taking part in the verification. So I am looking forward to Ethereum 2.0 coming soon.

    - There are already many projects that utilize the equity method, but I wonder what kind of enormous movement Ethereum, the second-largest project in total, will portray to enhance its scalability, including the conversion of the consensus protocol. Personally, I am as excited and worried as when I do hard fork after DAO hacking. In that sense, let’s first carefully watch for the rest of 2019 to see if Istanbul forks scheduled for November are successfully implemented and are well prepared to switch to Ethereum 2.0 by the end of the year.

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월 02일(수) : Ropsten Testnet HF
     - 11월 중 : Mainnet HF(=Istanbul HF)

□ Ropsten Fork 정리

  ㅇ 무슨일이 어떻게 발행했나
    - 롭스텐 포크는 예상일인 10월 2일보다 2일 일찍 발생하였다. 누군가가 약 1.5기가 해시를 갖고 채굴하고 있었고 그 채굴자는 기존체인을 밀고 있었다. 현재 그 거대 채굴자는 비(非) 이스탄불 체인을 이어가고 있으며, 그탓에 롭스텐 네트워크가 불안해졌고 많은 노드들 역시 비(非) 이스탄불 노드들이기 때문에, 우리는 그 네트워크에서 무슨일이 벌어지고 있는지 파악해오고 있다.
    - Geth 클라이언트 사용자들로 하여금 비(非) 이스탄불 체인을 걸러내고 있지만, Parity 클라이언트 사용자들은 잘 모르겠다. 사실 우리는 미래에 이런 상황을 방지할수 있는 몇가지 선택지가 있다. 하지만 롭스텐의 경우, 수정을 추가하기엔 너무 늦었다.
    - 개발자들은 롭스텐에서 마지막으로 작업했을때 몇가지 문제들이 발행했지만 누구도 연락하지 않았다. 다만, 이전에만 하더라도 체인을 다루는데에 좋은 테스트라고 생각했지만, 디앱 개발자들의 기분이 좋지 않았습니다. 그럼에도, 더 긴 체인을 이어가기 위해 클라이언트가 어떻게 행동하는지 지켜보는 것은 매우 흥미롭다.
    - 어쨌든 롭스텐 사태가 발생했지만, 메인넷에서는 거대 채굴자들에 의해 이스탄불 체인이 밀려날 가능성이 크지 않다고 보기 때문에 큰 걱정은 하지 않는다.

□ 이더리움 로드맵 2020 : 커뮤니티 토론(데브콘5)

  ㅇ 이더리움 커뮤니티 토론 at Devcon5
    - 데브콘5 첫날 이더리움1.0, 1.x, 2.0의 로드맵을 논의하기 위한 세션이 있을것입니다. 관심이 있는 분들은 여기에 참여하여 핵심개발자와 토론하시기 바랍니다.

 < 커뮤니티 토론 개요 >
    - 일시 : 2019년 10월 8일(목) 오후1~5시
    - 장소 : 컨벤션 룸(200석 이상)
    - 내용 : Ethereum1.0과 Ethereum2.0에 기여한 사람들과 이해당사자들을 위한 Ethereum magicians이 조직한 토론회
   ※ 자세한 내용은 여기 클릭

□ 빙하기(Ice Age)

  ㅇ 빙하기 해제 시기
    - 빙하기 EIP는 특별한 명분이 없기때문에 이스탄불 포크에 포함시키지 않을것이다. 현재 이스탄불이 정의되어있고 롭스텐 포크가 일어났기 때문에 빙하기를 적용하는것은 무리가 있다. 또한 일부 개발자의 계산에 따라서, 빙하기를 이스탄불에 포함시키기 보다는 또다른 포크에 적용하기 위한 충분한 시간을 갖기로 한다.

□ 테스팅 업데이트

  ㅇ 포크ID정의
    - Eth64를 포크ID*로 정의하고, 롤아웃하자는 Geth팀에 반대의견이 있는 사람은 2주이내에 AllCoreDevs에 이의를 제기한다.
     *포크ID : 블록체인의 고유 식별자로, 포크시 기존 메인체인의 고유 식별자(ID)와 구분하기 위해 생성된다. 이렇게 포크ID가 새로 정의되면 리플레이 어택 등의 문제를 미연에 방지될수 있다.

   ※ 이스탄불HF 적용 EIP
     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사용을 불허함.

□ 개인 논평

  ㅇ 포크와 작업증명방식
    - 이스탄불 테스트넷 중 하나인 롭스텐이 예상보다 일찍 포크가 발생하였는데, 그 이유는 그만큼 빨리 채굴되었다는 것이다. 즉, 평소보다 블록을 검증하는 데 걸린 시간이 줄어들었단 말이다. 익히 알려진대로, 포크가 발생하면 채굴자들은 포크에 걸맞는 새로운 버전을 직접 업그레이드해야하므로, 그만큼 채굴자의 의지와 협조가 중요하다.
    - 하지만 롭스텐 포크의 경우, 엄청난 해시를 지닌 채굴자가 포크체인이 아닌 기존체인을 이으면서 노드들이 어떤 버전의 체인을 따라야하는지 혼란스러워 하는 등 네트워크가 불안해졌고 여기서 비(非) 채굴자인 이더 보유자들은 최대한 안전한 지갑에 이더를 보유할 뿐 딱히 할수 있는것이 없다. 이것이 바로 작업증명방식(PoW)의 특징이자 단점이다. 만약 이더가 지분증명방식(PoS)이었다면 본인 이더를 유효지분으로 예치하여 검증에 참여(Staking)하면 직접 네트워크 유지에 기여할수 있는 분산된 권한이 주어진다. 그래서 곧 다가오는 이더리움2.0이 기대된다.
    - 지분증명방식을 활용하는 프로젝트가 이미 많이 있지만 시총2위의 거대 프로젝트인 이더리움이 합의프로토콜의 전환을 포함하여 확장성을 높이는 어마어마한 움직임이 어떤 모습을 그릴지 궁금하다. 개인적으로는 DAO해킹이후 하드포크를 할때만큼 또는 그 이상으로 설레고 걱정이 된다. 그런의미에서 우선 2019년 남은 기간동안, 11월쯤으로 예정되어있는 이스탄불 포크가 성공적으로 이행되는지와, 연말까지 이더리움2.0의 전환 준비가 잘 되고 있는지 주의깊게 지켜보도록 하자.

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

댓글 쓰기

0 댓글