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

#74 Devs Meeting Review(1 Nov 2019)

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



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

□ Istanbul HF update

  ㅇ Istanbul HF block number
    - Hudson said block number for Istanbul was born; 9,069,000, asking when clients are releasing an update with the [Istanbul] block number attached.
In response, Tim replied by mid-November, within two weeks.
- Hudson also said the Ethereum Foundation and/or Ethereum Cat Herders are publishing a blog on the block number and what software to upgrade when host clients update their download links.


□ Finally accepted EIPs in 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.


□ Berlin HF

  ㅇ Ice Age (Ice Age)
    - Tim said we said that the Ice Age would start kicking in next summer, please correct me if I'm wrong. We probably want an EIP in Berlin that kicks back the Ice Age.
Hudson noted that James Hancock decided to write the EIP with no need to rush.

  ㅇTentatively Accepted EIPs in Berlin 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.
     9) EIP-1559 : Away from current inefficient and unnecessary gas costs, this will adjust basic network charges according to network demand, increase cost efficiency, and increase user convenience in gas charge.


□ Discussing the process and schedule

  ㅇDiscusson on EIPs and forks
    - Alex said that for every EIP change, record a decision in the meeting notes so EIP editors can extract on the meeting notes, for standing PRs.
    - James said that all EIPs, except for the ice age that needs to be updated every month deciding whether to go or to postpone. He also said that We want to avoid one fork per EIP, as well as waiting significant time to include several EIPs, as both limit implementations, testing, etc.In response, Hudson added that for most EIPs, we can decide, implement, and do tests for an EIP within a 3-4 week period as well as the champion of an EIP and the coordinator for testing.


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.




(한국어 버전)

□ 이스탄불HF 업데이트

  ㅇ 이스탄불HF 블록넘버
    - Hudson은 이스탄불HF 블록넘버가 9,069,000으로 정해졌다고 말하면서, 언제 클라이언트들이 블록넘버가 첨부된 업데이트 버전을 출시하는지 물었다.
이에 Tim은 2주이내인 11월 중순까지라고 답했다.
    - 또한 Hudson은 이더리움재단과 이더리움 캣허더가 블로그를 통해 블록넘버와 클라이언트의 업데이트 버전을 게시할거라고 말했다.

  ㅇ 이스탄불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사용을 불허함.


□ 베를린HF

  ㅇ 빙하기(Ice Age)
    - Tim은 일전에 우리는 내년 여름에 빙하기가 시작될거라고 말했는데, 아마도 베를릴HF때 빙하기를 중단하는 EIP가 필요할지도 모른다고 말했다.
이에 Hudson은 James가 그 EIP를 작성하기로 했고 크게 서두를 필요가 없다고 언급했다.

  ㅇ 잠정승인 EIP
     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 : 프리컴파일에 대한 정적호출의 가스비를 줄임으로서, 파일사용이 보다 효율적.
     9) EIP-1559 : 현재의 비효율적이고 불필요한 가스비가 드는 방식을 벗어나, 네트워크 수요에 따라 기본 네트워크 요금을 조정하고 비용 효율성을 높이며 가스비지불에 있어 사용자 편의성을 높임.


□ 과정 및 일정 논의

  ㅇ EIP와 포크
    - Alex는 모든 EIP변경에 대해 회의록에 결정사항을 기록하여 EIP작성가 코드변경을 실행할 수 있도록 하게 하자고 말했다.
    - James는 업데이트가 필요한 빙하기를 제외한 모든 EIP는 특정실행시점을 정하기보다 매월 실행할지 지연할지 결정할수 있다고 말했고, 또한 EIP당 하나의 포크를 지양하고 여러 EIP에 대한 테스트, 구현 등을 위해 상당한 시간을 갖길 선호한다고 밝혔다. 이에 Hudson은 대부분의 EIP의 경우, 우리는 3-4주내에 테스트, 구현을 할수 있고, 누가 테스트할지 담당할지 정할수 있다고 첨언했다.


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

[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관련자들이 그것에 덜 관심갖게 된 이유는 더 많은 인적자원들이 있어서 이전보다 남들이 대신 해줄거라는 기대감이 더욱 커졌기 때문이라고 지적했다. 
   


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

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

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