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

#70 Devs Meeting Review(6 Sep 2019)

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



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
     - Oct 02(Wed): Testnet HF
     - Nov ?? : Mainnet HF(=Istanbul HF) 


□ Istanbul HF-related client update

  ㅇ Whether to merge Istanbu lHF-related EIP by clients
    - (Pantheon) All Merged.
    - (Geth) All Merged.
    - (Trinity) There is an issue. It is working but it is too slow.
    - (Parity) We are going to wait to discuss Blake F before we hit the merge button.
    - (Aleth) No one available to speak on Aleth.
    - (Nethermind) We are all ready and are just waiting on the tests.


□ "Patch proposals" for Istanbul

  ㅇ EIP-152 issue
    - There is confusion because the EIP associated with Blake2 has different names such as Blake2b(precompile), Blake2f(function), Blake2bf(function). Currently, the EIP-152 focuses only on specific configurations of Blake2b, and has 12 rounds. Even if F function is specified, it is only one function in Blake2b.
    - Specifying certain functions or deleting rounds from a test perspective is not a big deal 
and can easily be modified.
    - Therefore, EIP-152 is specific to Blake2b, that is it is fixed to 12 rounds.

  ㅇ EIP-1884 issue
    - Although there was disagreement among devs on exactly how to deal with security issues related to EIP-1884, they agreed to make the most modifications before Istanbul HF.
    - Etherum Cat Hurders will create communication to review issues related to EIP-1884.
     ※ In the last meeting, a dev called Wei mentioned in relation to EIP-1884 that there must be a solution before Istanbul HF, that there will be no interruption of the contract by increasing the gas stipend of smartcontracts(opcode), and devs will discuss this security issue.

□ Decide block number for Istanbul testnet/mainnet

  ㅇ Client updates and mainnetHF schedules
    - Assume that all clients can update by the following weekend(Sep 14), and require 
    two weeks of time.
    - Therefore, testnet HF should be on October 2 and the block number closest to this date 
should be selected. 
   
  ※ 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.


□ Least Authority ProgPoW Initial Audit Report (LA team in attendance)

  ㅇ Audit Initial Report
- According to an audit conducted by Least Authority, an Internet security solution provider, 
the company said that it had achieved a high level of design as originally intended and 
achieved sufficient economic effects. However, they expected some potential attacks 
but there is a solution accordingly.


□ Personal Comments
  ㅇ Istanbul HF and Etherium1.x
      - IstanbulHF is Etherium's eighth-ever upgrade and virtually the first in Etherium1.x. While the community is getting only interested in Etherium 2.0 as well as the release of its specifications and news reports, Ethereum1.x, which will coexist with Etherium 2.0 for the next three to five years, is also important.
    - The position we should have in this process is to understand the delay of development with patience. The Istanbul HF is expected to be delayed by at least a month from its original schedule, as was the case with the previous HF. I was also unhappy as an analyst and investor because Casper was delayed, not to mention HF, but after studying Ethereum, I found the reason for the delay and the complaints disappeared considerably. While we are worried that the delayed development will undermine Ethereum brand value and discourage investment sentiment, we should remember that it takes time to identify and review unexpected issues to make this already huge project go smoothly.
    - To share that time of patience, I will continue to share the Ethereum devs meeting and news, especially more with Etherium 2.0. We now share the pain, but let me finish my personal comments by waiting for the day to come when we share joy.


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일(수) : 테스트넷HF
     - 11월 중 : 메인넷HF(=이스탄불 HF) 

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

  ㅇ 클라이언트별 이스탄불HF 관련 EIP 병합 여부
    - (Pantheon) 모든 EIP 병합.
    - (Geth) 모든 EIP 병합.
    - (Trinity) 문제가 생겨 조사중.
    - (Parity) 병합하기 전에 Blake F에 대한 논의가 필요함.
    - (Aleth) 관계자 회의 불참.
    - (Nethermind) 테스트넷HF 준비 완료.

□ 이스탄불HF에 대한 패치 제안

  ㅇ EIP-152에 대하여
    - Blake2와 관련된 EIP가 Blake2b(precompile), Blake2f(function), Blake2bf(function) 등 서로 다른 이름을 갖고있어 혼란이 있다. 현재 EIP-152는 Blake2b의 특정 구성에만 초점을 맞추고 있으며, 12개의 라운드를 갖고 있다. 설령 F 함수를 적용하더라도 Blake2b안의 특정 기능일 뿐이다. 
    - 테스트 관점에서 특정 기능을 적용하거나 라운드를 삭제하는 것은 큰 문제가 되지 않으며 수정이 가능하다. 
    - 따라서, EIP-152는 F 함수를 제거하고 Blake2b에만 적용한다. 

  ㅇ EIP-1884에 대하여
    - EIP-1884와 관련된 보안 문제를 정확히 어떻게 다뤄야할지 개발자들 사이에서 의견이 분분했지만, 이스탄불HF 이전에 최대한 수정해야하는 데에는 의견을 모았다.
    - Ehtereum Cat Herders는 EIP-1884 관련 문제를 검토하기 위하여 대한 커뮤니케이션을 만들기로 한다.
     ※ 지난 회의에서 한 개발자(Wei)는 이스탄불HF이전에 반드시 해결해야 하는 것이 있다면서, EIP-1884와 관련하여, 스마트컨트렉트(opcode)의 가스 소모량을 높여야 계약이 멈추는 일이 없을거라는 언급을 하였고 개발자들은 이 보안 문제에 대하여 논의하기로 하였음.

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

  ㅇ 클라이언트 업데이트와 메인넷HF 일정
    - 다음 주말(9월 14일)까지 모든 클라이언트가 업데이트를 할수 있다고 가정하고, 그로부터 2주간의 시간이 필요하다.
    - 따라서 10월 2일(수)에 테스트넷HF를 하기로 하고, 이 날짜와 가장 가까운 블록 넘버를 선택하기로 한다.
    

□ ProgPoW 감사

  ㅇ 감사 최초 보고서
    - 인터넷 보안 솔루션 전문 업체 Least Authority가 진행한 감사에 따르면, 애초에 의도된대로 높은 수준의 설계를 이뤘고 충분한 경제적 효과*를 달성하였다고 하였다. 다만, 관계자는 일부 잠재적인 공격이 예상되지만 그에 따른 해결책이 있다고 하였다. 

  ※ 이스탄불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와 이더리움1.x
    - 이스탄불HF는 이더리움의 역대 8번째 업그레이드이자 이더리움1.x에서의 사실상 1번째 업그레이드다.  이더리움2.0에 대한 스펙 공개와 뉴스들이 나오면서 이더리움2.0에만 관심이 커지고 있지만, 향후 3~5년간 이더리움2.0과 공존할 이더리움1.x 역시 그 중요성을 무시할수 없다.
    - 이런 과정에서 우리가 가져야할 자세는 개발의 지연을 인내로 승화하는 자세다. 이전 HF가 그랬듯 이번 이스탄불HF도 예정된 일정보다 최소 한달간 지연될 전망이다. 필자도 HF는 물론이고 캐스퍼가 지연되어서 분석가이자 투자자로서 불만이 많았지만 이더리움을 연구하다보니 지연된 이유를 알게되었고 불만이 상당히 사라졌다. 지연되는 개발 상황때문에 이더리움 브랜드 가치가 훼손되지 않을까 걱정이 되고 투자심리도 위축되지만, 이미 거대한 프로젝트가 되어버린 이더리움을 순조롭게 진행시키려면 예상치 못한 문제들을 파악하고 검토하는 시간이 필요하다는 사실을 기억하자. 
    - 그런 인내의 시간을 같이 감내하는 의미로 필자는 앞으로도 이더리움 개발자 회의와 뉴스를 공유할것이며, 특히 이더리움2.0에 대해서도 공부한 내용을 공유할 계획이다. 지금은 고통을 나누지만 언젠가 기쁨을 나누는 날이 오길 기다리며 논평을 마치겠다.



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

댓글 없음:

댓글 쓰기

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

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