[Raven] Raven Devs Meeting(13 Sep 2019) // 9월 13일 레이븐 개발자 회의 분석 및 논평 v1.0

Raven Devs Meeting(13 Sep 2019) // 9월 13일 레이븐 개발자 회의 분석 및 논평


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

□ Analysis of the meeting by subject

  ㅇ Introduction to 2019 Ravencoin Asia Meetup
    - Tron Black('Tron' from here) shared '2019 Ravencoin Asia Meetup'* link at the beginning of the meeting and asked who was participating in the meetup.
     *This event will show the unity and support of Raven community and is arousing expectations and interest from Raven supporters, in Asia, especially in Korea(click here).

  ㅇ Current status of testnet development
    - A dev asked about the functions of messaging, restricted assets and dividends being tested on testnet and Tron said that he hoped that the functions of testnet would be onto mainnet by October 31but hated to push it as a hard deadline, because safety is import.

  ㅇ Raven communication channel and Raven Foundation
    - Although not all activated, there are many Raven communication channels such as Discord, Telegram, Reddit, Twitter and Bitcointalk, a dev said. Another dev said that someone once proposed 'foundation' and that it could be established in time. 
    - Devs including Tron, said it was a good idea to set up foundation and that they wanted to contribute, especially on the direction of the foundation, Tron said.
    - Also, some dev has already said that somebody created Raven Classic group to copy the current development. However, some suggested that rasing and spending funds(after the foundation's establishment) would not be easy and would have risks for a centralized group or governance.
     * The 'someone' is zimm(Carl) who participated in the last meeting, and he asked during the meeting why decentralization is important and why GPU should be more advantageous for mining than ASICs

  ㅇ Current status of support for fork updates in mining pools and exchanges
    - According to the current status of support for the base fork update till now, Bittrex and F2pool have not yet to reveal support the fork. Tron said he has feelers out to people in Bittrex, looking for a 100% positive response back.

  ㅇ Argument on ASIC, ASIC and ASIC
    - A dev raised the question that after the fork, the existing Ravenchain could be inherited 
by powerful ASIC mining groups to create a better chain, saying that all community members would not agree with the fork(scheduled for October) and that it might become a 'mouse and cat fighting'Another dev said the upcoming fork is a good deal but we need a long-term planwhile some claimed that Traysi Composed in Discord a while ago that something for long term essential resistance is in place.
    - When asked how much the Tiger algorithm to be added to the fork in October could prevent ASICs, Tron replied that the X16Rv2(with the Tiger) could never stop ASICs forever, only slowing down another entry. 
    -  (As the ASIC debate becam more intense) Some dev doubted whether adding Tiger algorithms is to please community(sort of populism) or to really ditch ASICs. Plus, he said we need somehow reach that step with having asics distributed and open to public for purchase. Some added that ASICs are as easy to mine as GPUs to give up ASIC resistance. 
    - In the proposal to introduce CNv4* to block ASICs, Tron said it's possible, but it needs to be evaluated to see if it's really good. Also, he said it may be tricky to put into mobile which on our mobile Wallet will be independently valid blocks while others said CNv4 make us no longer GPU, and only CPU if i'm not mistaken, and CPU are run by botnets.
     *CNv4: This is Monero's ASIC resistance algorithm, which is also a potential choice for Raven, but the CPU-friendly method still requires more consideration. 
     **botnets: Malicious software that is used to use the computer without the knowledge of the computer's owner



□ Personal Comments

  ㅇ Keeping justification vs. Horse trading
    - At the end of 2009, Satoshi said we should have a gentlemen's agreement to postpone the GPU arms race as long as we can for the good of the network. However, within a year since then, GPU has been excavated, and by the first halving of bitcoin in November 2012, 
ASICs for Bitcoin mining have been introduced. The ASIC was 1) economical enough to earn more than the machine price for a few days of mining, and 2) raised the level of mining that was at that time hobby level to a more serious level3) Since then, large-scale mining companies including F2pool have been established and various business models such as mining dividends have been introduced. And the ASIC mining race has reached up to now. 
    - Although I have continuously watched projects such as Bitcoin and Lightcoin that have let ASIC mining live and projects such as Ethereum and Monero that still try to resist ASICs, I have thought about ASIC again while watching Raven devs meeting this time. My personal conclusion so far is that "Raven must resist ASICs"The reason is as follows. First, it is because of symbolic reasons for the promise. From the beginning, Raven introduced a new algorithm, x16r, to prevent ASIC mining, which is the same as promising ASIC resistance that made Raven devs and communities have at least a right and a duty to support Raven's justification and identity. Second, it is for practical reasons for survival. Although I have repeatedly emphasized that ASIC resistance is a matter of survival if development of functions such as messaging, limited assets, and dividends is a matter of well-being. Some argue that certain mining pools dominate more than 60 percent of Raven hash, and that the continued forks of new ASICs will disrupt communities and networks. I think the opinion is fully understandable. However, it is difficult to compare "abandonment by prediction of disruption" with "efforts to improve the body despite the risk of distruption". So far, it is just a fork that adds a sub-alignment, Tiger, but after a number of trials and errors, it may come up with an great idea that no dev team has ever thought of. 
    - I can't deny that it's going to be an extremely difficult fight, even though I've been convinced about what I just said. Nevertheless, in my humble opinion, I still fully sympathize with Tron's opinion that attempts and efforts should be made to resist ASICs. Unless Raven ecosystem and networks are at a dead end, and it is difficult to keep the promise with the community agreed on let ASICs live, then I don't know. But again, I don't think that's the time yet, and I hope our community will pay great attention to ASIC resistance as well as testnet development situation.

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.





(한국어) 

□ 소재별 회의 내용

  ㅇ 2019 레이븐코인 아시아 밋업 소개
    - 트론블랙(이하 '트론')은 회의 초반에 '2019 레이븐코인 아시아 밋업'*링크를 공유하면서 누가 이 밋업에 참여하는지 물었다.
     *이 밋업은 레이븐 커뮤니티의 결집과 지지를 보여줄수 있는 행사로 아시아 특히 한국에서 레이븐 지지들의 기대와 관심을 불러일으키고 있음(자세한 정보와 참여 신청은 여기 클릭)

  ㅇ 테스트넷 개발 현황
    - 한 개발자가 테스트넷에서 테스트중인 메시징, 제한자산, 배당 등의 기능에 대해 물었고, 10월 31일까지 테스트넷의 기능들이 메인넷으로 이동되길 바라지만 체인 안전성이 중요하기때문에 기한내 완료되기를 압박하고 싶지 않다고 트론은 말했다.

  ㅇ 레이븐 소통채널과 레이븐 재단 설립
    - 비록 활성화되어있지 않지만, Discord, Telegram, Reddit, Twitter, Bitcointalk 등 다양한 레이븐 소통채널이 있다고 한 개발자는 말했다. 또다른 개발자는 예전에 누군가 '재단 설립'을 제안하였다면서, 때가 되면 설립될수도 있을거라고 말했다. 
    - 이에 트론을 포함한 개발자들은 재단 설립은 좋은 생각이라고 했고 그 설립에 기여하고 싶다고 말했고, 특히 재단 설립 방향에 대하여 투표를 통하는게 좋을것 같다고 트론은 말했다.
    - 또한, 어느 개발자는 이미 누군가* 레이븐클래식 그룹을 만들어서 현재 레이븐 채널을 흉내낼수있다고 말했다. 다만, 몇몇은 (재단 설립 이후) 자금을 모으고 지출하는 것 등이 쉽지 않고 중앙화된 집단을 리스크를 동반할것이라는 의견을 냈다.
     * 그 '누군가'는 지난 회의에 참여했던 zimm(Carl)로, 그는 회의중에 '왜 탈중앙성이 중요하냐', '왜 GPU가 ASIC보다 채굴에 더 유리해야하냐' 등의 질문을 했음

  ㅇ 채굴풀, 거래소의 포크 업데이트 지원 현황
    - 9월 14일 현재 기준 포크 업데이트 지원 현황에 따르면, 비트렉스와 F2pool이 아직 지원하겠다고 밝히지 않았다. 이에 트론은 자기가 생각하기에 비트렉스는 100% 업데이트할것이라고 말했다.

  ㅇ ASIC에 대한 갑론을박
    - 한 개발자가 모든 커뮤니티 일원이 (10월로 예정된) 포크를 동의하지도 않는다며, 향후 ASIC의 존재가 발견되면 또다른 포크를 하는 등 '쥐와 고양이' 싸움이 될지도 모른다고 말하면서, 포크이후에 ASIC채굴집단에 의해 기존 레이븐체인을 이어받아 더 좋은 체인을 만들수 있다는 의문을 제기하였다. 이에 다른 개발자는, 포크는 좋은 대책이지만 몇달마다 포크를 해도 되지 않는 장기계획이 필요하다고 말했고, 또다른 개발자는 ASIC저항을 위한 장기대책을 누군가(traysi)가 일전에 밝힌적이 있다고 첨언하였다.
    - 10월 포크에 추가될 Tiger 알고리듬이 얼마나 ASIC을 막을수 있을지 누군가 묻자, 트론은 (Tiger를 장착한) X16Rv2는 ASIC을 영원히 막을수 없고, 단지 또다른 진입을 늦출 뿐이라고 답했다. 
    - (ASIC 논쟁이 심화되면서) 어떤 개발자는 Tiger 알고리듬을 추가하는 것이, 커뮤티니를 즐겁게 하는 행위(일종의 포퓰리즘)인지 정말 ASIC을 저항하기 위한 행위인지 의문이라며, 우리는 어느정도는 ASIC채굴에 의한 해시 분산과 ASIC판매를 대중화할 필요가 있다고 말했다. 이 의견에 누군가는, ASIC저항을 포기할정도라면 ASIC이 GPU만큼 채굴하기 용이할 수준이어한다고 의견을 보탰다. 
    - ASIC을 막기위해 CNv4*을 도입하자는 제안에, 트론은 가능은 하지만 그게 정말 좋은지 평가할 필요가 있다고 말했고, 다른 이들은 CNv4는 모바일 지갑에 구현하기 애매하고, 그리고 봇넷**에 의한 CPU채굴이 해시를 장악할거라고 말했다. 차라리 이미 기존ASIC이 즐비한 비트코인 알고리듬(sha256)으로 전환하자는 제안에, 트론은 x16r이 훨씬 더 안전하다고 잘라 말했다.
     *CNv4: 모네로의 ASIC 저항 알고리듬인 CNv4 도입 역시 레이븐의 잠재적인 선택지지만, CNv4는 CPU친화적이라는 의견이 지배적이라 좀 더 많은 검토가 필요함. 
     **봇넷(botnets): 컴퓨터 주인 몰래 그 컴퓨터를 사용하기 위해 심는 악성 소프트웨어를 의미



□ 개인 논평


  ㅇ 대의명분 수호인가 현실타협 부상인가
    - 2009년 말 사토시는 네트워크를 위해 GPU채굴 경쟁을 늦춰야한다고 말했다. 하지만, 그로부터 1년도 되지 않아 GPU채굴장이 나왔고, 2012년 11월 비트코인의 첫 반감기때쯤, 비트코인 채굴전용 ASIC이 세상에 나왔다. 그 ASIC채굴기는 1) 며칠만 채굴하면 기계값 이상을 벌수 있을정도로 경제적이었고, 2) 당시 취미 수준에 머물렀던 채굴을 좀 더 진지한 수준으로 끌어올렸으며, 3) 이후 F2pool을 비롯한 대규모 채굴업체가 설립되고, 채굴배당같은 다양한 비즈니스 모델이 나오는 등 산업화를 이루는데 기여를 하였다. 그리고 ASIC채굴 경쟁은 현재까지 이른다. 
    - 필자는 ASIC채굴에 여지를 둔 비트코인, 라이트코인 등의 프로젝트와 ASIC채굴에 여지를 주지 않으려고 하는 이더리움, 모네로 등의 프로젝트를 꾸준히 지켜봤지만, 이번 레이븐 개발자회의를 보면서 다시한번 ASIC에 대한 생각을 곰곰이 해봤다. 현재까지 내린 개인적인 결론은, 현재까지는 "레이븐은 ASIC을 저항해야 한다"이다. 그 이유는 다음과 같다. 첫째, 약속에 대한 상징적인 이유때문이다. 레이븐은 처음부터 ASIC채굴을 막기위해 새로운 알고리듬인 x16r을 도입하였고, 그것은 ASIC 저항을 약속한 것과 같다. 레이븐 개발자들과 커뮤니티는 레이븐의 그런 대의명분과 정체성을 지지하였기에 최소한 그것을 지지할 권리와 의무가 있다. 둘째, 생존에 대한 현실적이 이유때문이다. 필자가 누차 강조했지만 메시징, 제한자산, 배당 등의 기능 개발이 '웰빙의 문제'라면 ASIC저항은 '생존의 문제'이다. 혹자는 특정 채굴풀이 레이븐 해시의 60%이상을 장악하였고, 계속되는 ASIC채굴기 출시에 따른 계속된 포크는 커뮤니티와 네트워크를 분열할것이라고 주장한다. 필자도 그 의견이 충분히 일리있다고 생각한다. 하지만, '분열이 될거라는 예측에 의한 포기'와 '분열 리스크가 있음에도 체질개선을 하려는 노력'은 비교하기 어렵다. 아직까지는 서브알고리듬 하나를 추가하는 포크이지만 여러 시행착오 끝에 그 어떤 개발팀도 생각하지 못한 묘안이 나올수 있다. 
    - 필자도 말은 호기롭게 했지만 정말 쉽지 않은 싸움이 될것이라는 사실은 부인할수 없다. 그럼에도 개인적인 생각에는, ASIC 저항을 위한 시도와 노력을 해야한다는 트론의 의견에 아직까지 전적으로 공감한다. 만약 레이븐 생태계와 네트워크가 존폐의 기로에 서지 않는 수준에서, 수많은 시도들을 했음에도 어렵다면, 커뮤니티의 동의를 구한다면 모르겠다. 하지만 다시 말하지만 그때가 아직 오지 않았다고 생각하며, 우리 커뮤니티도 테스트넷 개발 상황 뿐만 아니라 ASIC저항에도 큰 관심을 가져주시기 바란다.


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

[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에 대해서도 공부한 내용을 공유할 계획이다. 지금은 고통을 나누지만 언젠가 기쁨을 나누는 날이 오길 기다리며 논평을 마치겠다.



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

[News] '디지털 위안'과 '페이스북 리브라' // Digital yuan and Facebook Libra

New head of China's digital currency says it beats Facebook Libra on tech features.

중국의 디지털 통화를 담당하는 새로운 수장은 디지털 위안이 페이스북의 리브라보다 기술적으로 더 낫다고 말하다.


<원문기사링크 : https://www.coindesk.com/new-head-of-chinas-digital-currency-says-it-beats-facebook-libra-on-tech-features >

□ 기사 내용

The Chinese central bank has a new digital currency chief who says its upcoming digital yuan has features not offered by Facebook Libra.
중국 중앙은행은 디지털 통화를 담당할 새로운 수장을 임명하였으며, 그에 따르면 곧 출시될 디지털 위안의 기능이 페이스북 리브라에는 없다고 말했다.

Changchun Mu – previously deputy director of the payments and settlement division at the People’s Bank of China (PBoC) – recently stepped into the lead role at the Digital Currency Research Institute, reports Shanghai Securities News.

상하이증권뉴스에 따르면, 중국인민은행(PBoC)의 결제담당 부국장이었던 장춘무는 최근에 디지털통화연구소에서 중추적인 역할을 할것이라고 보도했다.

According to the state-run news source, Mu recently published details on PBoC’s digital currency – apparently being carried out in a secret office away from the bank’s Beijing headquarters – describing it as a digital currency and electronic payment tool with “value characteristics.”
국영 소식통에 따르면, 최근에 그는 베이징 본사에서 떨어진 비밀 사무실에서 만들어지고 있는 중국인민은행의 디지털 통화에 대한 세부사항을 발표하였고, 그 통화는 '가치 특징'을 가진 디지털 통화이자 전자 결제 도구라고 설명했다.

“Its functional attributes are exactly the same as paper money, but it is just a digital form,” Mu said.
그는 "그것의 기능 속성은 지폐와 동일하며, 형식이 단지 디지털일 뿐이다"라고 말했다.

Perhaps most notably, he set out some of the digital currency’s technical aspects, and compared it with Facebook’s Libra.
아마도 가장 눈에 띄는 것은, 그가 디지털 화폐의 기술적 측면을 몇 가지 제시하면서, 그것을 페이스북의 리브라와 비교했다는 점이다.

PBoC’s digital yuan will be able to be transferred between users without an account and without a mobile or internet network, the report cites Mu as saying. Providing a user’s mobile phone has a wallet, the digital currency can be transferred to another person by placing the two phones in physical contact. Presumably, this feature is enabled by near-field communication (NFC).
이 보고서는 무의 말을 인용하면서 중국인민은행의 디지털 위안은 계좌 없이 그리고 모바일이나 인터넷 네트워크 없이도 사용자들 사이에서 송금될 수 있을 것이라고 밝혔다. 사용자의 휴대폰에 지갑이 있는 경우, 2개의 휴대폰을 물리적으로 접촉하여 그 디지털 통화를 상호 전송할 수 있다. 아마도 이 기능은 근거리 통신(NFC)에 의해 활성화될 것이다.

“Even Libra can’t do this,” Mu said.
무는 "페이스북의 리브라에는 이런게 없다"라고 말했다.

PBoC’s digital currency also doesn’t need a bank account to be used, and is “free from the control of the traditional bank account system,” Shanghai Securities News cites Mu as saying. He further suggested it allows users to preserve their privacy when using the system.
중국인민은행의 디지털 통화는 또한 은행 계좌를 사용할 필요가 없으며, "전통적인 은행 계좌 시스템의 통제로부터 자유롭다"고 상하이 증권 뉴스는 무를 인용하였다. 그는 또한 사용자들그 시스템을 사용할 때 그들의 사생활이 보호될 수 있도록 할것이라고 제안하였다.

However, the digital currency will be delivered via commercial banks like fiat currency. The banks must open accounts with the PBoC and buy the token at 100 percent value. After that, users may open digital wallets for the digital currency through the banks or commercial organizations.
하지만 그 디지털 통화는 법정 통화처럼 시중은행을 통해 전달것이다. 은행들은 중국인민은행을 통해 계좌를 개설하고 토큰을 정가에 구입해야 한다. 그런 다음에, 사용자들은 은행이나 영리단체를 통해 그 디지털 화폐용 전자지갑을 소지할 수 있다.

According to the report, Mu added that the main reason for developing the digital currency is “planning ahead” to protect monetary sovereignty and China’s legal currency. That may be a hint that the advent of Facebook’s Libra is behind the sudden rush of development at the central bank.
그 보고서에 따르면, 무는 디지털 통화를 개발하는 주된 이유는 통화 주권과 중국의 법정통화를 보호하기 위한 "사전 계획"이라고 덧붙였다. 그것은 아마도 페이스북의 리브라의 등장때문에 중국중앙은행이 갑작스럽게 개발하게 되었음을 암시한다.

Former People’s Bank of China (PBoC) governor Zhou Xiaochuan said in July that “Libra has introduced a concept that will impact the traditional cross-border business and payment system.”
저우샤오촨 前 중국인민은행 총재는 지난 7월 "리브라는 전통적인 국경 간 사업과 결제 시스템에 영향을 끼칠 새로운 개념을 도입했다"고 밝혔다.

As such, China should “make good preparations and make the Chinese yuan a stronger currency,” Zhou said.
그는 또한 이와 같이 중국은 "적절한 준비를 하고 중국 위안을 더 강한 통화로 만들어야 한다"고 말했다.



□ 개인 논평

  ㅇ 중국을 자극한 리브라
    - 지난 6월 페이스북은 자체 암호화폐 '리브라(Libra)'의 백서를 공개하면서 소셜 네트워크 뿐만 아니라 송금 분야에서도 거물이 될 야욕을 드러냈다. 한때 수천만명의 개인정보가 유출되는 초유의 사태를 겪었지만 20억명이 넘는 회원을 보유한 페이스북이 내놓은 프로젝트이기에 블록체인 영역에 큰 이슈가 되었다. 
    - 리브라가 대단한(또는 대단해 보이는) 이유는, 전에 없던 방식의 디지털 통화이기 때문이다. 알다시피, 페이스북은 미국 정부의 산하기관도 아니고 화폐발행권을 갖는 연방단체도 아닌 민간기업이다. 그 의미가 무엇이든 활용 비즈니스가 명확한 거대 기업이 돈을 만든다는 사실은 미국 정부와 금융권을 긴장시키는 것은 물론 중국, 러시아 등 다른 국가의 정부 역시 자극하게 만들었다. 
    - 그렇게 자극하게 만드는 이유는 다양하다. 첫째로 리브라는 특별하다. 아직 실체는 없고 백서에 나타난 스펙 뿐이지만, 20억명이 넘는 가입자와 수억의 활동적인 사용자들을 보유하는 것은 그 어떤 설명과 분석보다 직관적이고 명쾌하다. 둘째로 리브라는 강력하다. 만약 한 국가 안에서 해당 국가의 법정화폐의 일부, 가령 10%라도 리브라로 빠져나간다면, 그것도 일시적이 아닌 영속적으로 빠져나간다면 해당 국가와 당국은 해당 법정화폐의 위상과 매력도의 하락뿐 아니라 실질적인 유동성과 가치에도 영향을 받을수 있기 때문이다. 그렇다고 사람들이 원해서 쓰는 것을 무턱대로 막기도 어렵다. 셋째로, 리브라는 인상적이다. 정부 또는 정부가 위임한 연방 단체가 아닌 민간기업이 그것도 막강한 커뮤니티를 확보한 거대기업이 돈을 찍어내는 주체가 되었기 때문이다.  넷째로, 리브라는 상징적이다. 그 덕분에 다른 거대기업이나 각국 정부에서 디지털 통화의 주도권을 선점하거나, 달러, 위안 등 기존 자국법정화폐 덕분에 이미 높은 통화의 위상을 지키려는 움직임이 거세지게 될것이기 때문이다. 그 움직임 중 하나가 바로 위 기사에서 언급된 '디지털 위안'이다.

  ㅇ 왕서방의 블록체인 사업 수완
    - 중국인민은행(실제론 중국정부)이 끌어주고 중국은행과 관련 기업들이 밀어주는 디지털 위안은 아직 말뿐인 리브라보다 더 좋다고 벌써부터 떠들어댄다. 얼핏보면 자기가 갖고 있는 패를 보여주는 하수들이 하는 짓같지만, 필자가 보기엔 그럴만한 이유가 있는 듯하다. 첫째로, 리브라의 영향력은 국경을 넘어설수 있기 때문이다. 멀리 가지 않아도 인터넷이라는 좋은 예가 있다. 인터넷은 글로벌 커뮤니티이자 정보의 바다라는 수식어 답게 국경을 초월하지만 중국은 자신들의 주체사상을 지키거나 자국의 분열이 될만한 틈을 만들지 않기 위하여 인터넷마저 검열하는 나라다. 그런 중국이 국경을 초월하는 결제수단이자 다양한 금융상품의 모체가 될 리브라를 두팔 벌려 환영할리는 만무하다. 둘째는 자국의 디지털 통화를 만들기 위한 좋은 명분과 선전이 되기 때문이다. 이미 중국은 현금없이도 위챗페이 등 디지털 결제수단 활용이 매우 대중화된 나라다. 아마 디지털 위안이 출시되어도 중국인민들이 사용하기에 큰 위화감은 없을것이다. 그럼에도 불구하고 '우리 공산당은 인민을 위하여 보다 편하고 투명한 새로운 통화를 만들것입니다'라고 말하고 싶을것이다. 이렇듯 2가지 이유를 볼때, 중국은 '디지털 위안'을 통하여 리브라에 대해서 자신들이 할수 있는 최선의 방어와 최고의 공격을 할수 밖에 없는 것이다.

 ㅇ 정부/기업발 코인 사용 설명서
    - 한가지 유의해야 할 점이 있다. 리브라의 백서에 따르면, 탈중앙되어있고 보안이 뛰어나며 안정성이 높고, 유동성이 적으며, 글로벌 통용성을 지니며, 파트너쉽도 빵빵하다 등 좋은 점들을 나열해놨다. 어디서 본것같은 기분이 드는건 필자 뿐인가. 하지만 그들이 누구인가, 수시로 약관을 변경할수 있고 개인정보를 유출하게 만든 민간 기업아닌가. 저런 미사여구로 넘치는 '어음'같은 약속이 실제로 프로젝트가 구현되었을때 '현금'으로 돌아오리라고 믿고 싶지만 이윤을 창출해야하는 기업의 특성상 그게 지속될지는 매우 의문이다(물론, 리브라 협회의는 스위스에 설립된 비영리 단체다).
    - 중국인민은행이 만든다고 다를까. 퍽 하면 자국민 눈 가리고 귀 가리는 데 도가 튼 중국이 안전하고 투명한 새로운 통화를 만든다고 하면 지구 인구중 세계 77억명중 약 60억명은 믿지 않을 것이다(자국민 및 화교는 제외). 결론적으로는 '대중을 위한 투명하고 안전하게 결제가능한 수단'이 아닌 '기득권을 위한 투명하고 안전하게 검열가능한 수단'을 만드려는 의지가 엿보인다. 기분탓인지는 모르겠지만, 비트코인과 이더리움이 위대해보이는 요즘이다.


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

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

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