[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억명은 믿지 않을 것이다(자국민 및 화교는 제외). 결론적으로는 '대중을 위한 투명하고 안전하게 결제가능한 수단'이 아닌 '기득권을 위한 투명하고 안전하게 검열가능한 수단'을 만드려는 의지가 엿보인다. 기분탓인지는 모르겠지만, 비트코인과 이더리움이 위대해보이는 요즘이다.


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

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

Raven Devs Meeting(30 Aug 2019) // 8월 30일 레이븐 개발자 회의 분석 및 논평


(English) 한국어 버전은 아래쪽에 있음

□ Analysis of the meeting by subject

  ㅇ Ongoin 'ASIC' Debate
    - Tron Black('Tron') said the algorithm change will be at 16 October(UTC) which has has already been announced on 20 August. And some devs said that the hash and difficulty of mining suddenly skyrocketed for the last few days, raising the question of whether ASIC miners are mining with all the strength until changing the algorithm. For your information, 'Tiger' algorithm that will be in front of three existing algorithms was added to another coin, Tron said. Plus, 'X16rv2' will be a message to disable the current ASIC while resisting ASICs indeed, a dev said.
    - Also, when asked how much decentralization is important to Raven, Tron said it is very important, and ASIC could cause centralization. In fact, the one who asked about decentralization had unpleasant questions such as, 'Why should GPU miners be more advantageous for mining than ASIC miners' and 'Can the survey about the algorithm change be manipulated?' and embarrassed other devs.
    - The new algorithm will be on testnet on 3 September.
    - Some devs asked if the fork date could be 15 September, saying that ASICs could damage Raven by mining severely until 1 October, and others expressed disapproval of the question, saying 1 October is also 'soon'. The demage could be a 51% Sevbil attack or Reorg. Therefore, exchanges and mining pools must update, and if the update goes well, new Ravencoin will be worthless even if it comes out, otherwise it will be a problem, Tron said.
    - Another proposal was to develop a multi-algorithm chain. In other words, it is to develop the algorithms favorable to GPU, FPGA, and ASICs altogether.
    - Some dev said that ASICs sometimes use FPGAs for controlling mechanism, and that in that case, Tiger algorithm may have already been active in FPGAs.

  ㅇ Development progress
    - Tron said functions such as messaging, memos, tags and restricted assets are currently on testnet and rewards/dividends will soon be on testnet.
    - Plus, testnet with restricted asset is the same as testnet of the algorithm change.

  ㅇ Reduction in Ravencoin distribution
    - A dev proposed to reduce the amount of Ravencoin distribution to 16 billion from the current 21 billion at the upcoming fork, and again to 11 billion at the following fork. However, Tron and other devs disagreed with the proposal, saying that Ravencoin was burned when assets are issued.

  ㅇ Ravenland is over
    - Ravenland stops its operating for personal reasons, such as finances and health, and the resource said he is grateful for the positive response and support of Raven community over the past few years.

□ Personal Comment

  ㅇ Raven Vision(feat. Satoshi Vision)
    - Satoshi Nakamoto told an online forum in February 2009, shortly after Bitcoin was launched, that he  developed a new open source P2P e-cash system called Bitcoin. It's completely decentralized, with no central server or trusted parties.

< http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source >
    - Nine years later, Raven was launched to celebrate the 9th anniversary of Bitcoin's. Not just for fun, Raven has its unique algorithm called X16R and does not have a specific owner or operator to get decentralization. The algorithms for X16R have been fully explained before by me, so I will talk about no owner or operator. If you're asked what the advantages of Raven are when there is no particular operating entity like Bitcoin and you might answer that everyone can participate and develop, and there is no risk of being controlled by one or a few decisions. Then you only 50% understand. The lack of a particular operating entity is also sustainable because it is free from censorship by the government or authorities, a very realistic advantage at present when exchanges and projects run by some owner(s) are strictly regulated by the government or authorities.
    - In such Bitcoin and Raven's vision, such an obstacle has now emerged now, "ASICs". Since the launch of the first mass production ASIC in early 2013, a lot of networks based on proof of work have been dominated by ASICs or struggling to resist ASICs, with Bitcoin, Ethereum and Raven no exception. The reason why ASIC resistance is more important for Raven is that it started with its unique algorithms to preempt ASICs and promised its community sustainable decentralization from the beginning. This is why Raven devs are trying to fork to prevent ASICs based on the condition and community opinion.
    - But there's a saying that I've made up myself: 'There's no greater dev than community'. Looking back on human history, the success of innovation(revolution) has been on the support of the community(people) rather than the superiority of innovation(revolution), and foolish vested interests(the upper classes) had divided society whether they intended or not. Therefore, community must criticize and pressure devs as well as exchanges to keep up with the project's vision Let me show you a picture informing whether mining pools and the exchanges will participate in the upcoming update on 1 October. For our own Raven vision, let's watch, think and act.
< Whether to get updated on 1 October(as of 1 September) >


(한국어) 

□ 소재별 회의 내용

  ㅇ 계속되는 ASIC 채굴 논쟁
    - 트론 블랙(이하 '트론')은 10월 1일 16시(UTC기준)에 알고리듬이 변경될거라고 말했다(이는 이미 8월 20일에 공지된 바 있다). 그리고 일부 개발자들은 채굴 해시와 난이도가 갑자기 급등했다고 말하면서, ASIC 채굴자들이 (알고리듬 변경전까지) 가열차게 채굴을 하는게 아니냐라는 의문을 제기하였다. 참고로 이번 변경안에 추가된 타이커 알고리듬은 다른 코인에 적용된 선례가 있으며 기존에 존재하는 알고리듬 중 3개 알고리듬 앞에 추가될거라고 트론은 말했다. 이 X16rv2는 현재의 ASIC을 무력화함과 동시에 ASIC을 저항하는 메시지가 될것이라고 한 개발자는 밝혔다.
    - 또한, 어떤 회의참여자가 레이븐에게 있어 탈중앙성이 얼마나 중요하냐는 질문에, 트론은 매우 중요하다면서 ASIC은 중앙화를 야기할수도 있다고 답했다. 사실 그 질문을 한 참여자는 '왜 GPU채굴자가 ASIC채굴자보다 채굴에 더 유리해야하느냐', '알고리듬 변경을 위한 조사는 조작될수 있냐' 등 불쾌한 질문들을 했고, 다른 개발자들을 당황하게 만들었다.
    - 새로운 알고리듬은 9월 3일에 테스트넷에 올려질 예정이다.
    - 일부 개발자들은, (만약 존재한다면) ASIC채굴자들이 알고리듬 변경일까지 온 힘을 다해 채굴을 함으로써 레이븐에게 데미지를 줄수 있다고 말하면서 9월 15일로 포크 날짜를 당길수 있냐고 물었고, 다른 개발자들은 10월 1일도 머지 않았다면서 그 물음에 난색을 표했다. 여기서 말하는 데미지는 51% 해시장악을 통한 시빌 공격일수도 있고 리오그일수도 있다. 따라서 채굴풀은 물론 거래소들이 알고리듬 변경에 맞춰 업데이트를 반드시 해야하며, 업데이트가 잘 되면 새로운 레이븐코인이 나와도 가치가 없을것이지만 업데이트가 잘 되지 않으면 문제가 될거라고 트론은 말했다.
    - 다른 개발자도 또다른 제안을 했는데, 멀티알고리듬 체인을 개발하자는 내용이었다. 즉, GPU, FPGA, ASIC에 유리한 각각의 알고리듬을 개발하여 총 3개의 알고리듬을 병행하자는 제안이었다.
    - 한 개발자는 ASIC은 조정을 위하여 FPGA를 쓰는 경우가 있다면서, 그럴경우 타이거 알고리듬을 이미 FPGA에 반영했을수도 있다고 말했다.

  ㅇ 개발 진행 상황
    - 트론은 메시지, 메모, 태그, 제한자산 등의 기능들은 현재 테스트넷에서 계속 테스트 중이며, 배당 기능도 곧 테스트넷에 포함될거라고 말하면서, 로드맵을 향한 일정이 긴만큼 테스트가 필요하다고 말했다.
    - 참고로 제한자산 등의 기능이 올려진 테스트넷은 알고리듬 변경 테스트넷과 동일하다.

  ㅇ 레이븐코인 유통량 감소 제안
     - 한 개발자가 다가오는 10월 1일 포크때 레이븐코인의 유통량을 현재 210억개에서 160억개로 줄이고, 그 다음 포크때는 다시 110억개로 줄이자는 제안을 하였다. 하지만 트론을 비롯한 다른 개발자들은 자산을 발행할때 레이븐코인이 소각된다면서 그 제안에 공감하지 않았다.

  ㅇ 레이븐랜드(Ravenland) 종료
    - 레이븐랜드 관계자는 개발자 회의를 통해, 레이븐랜드 운영을 중단한다고 밝혔다. 중단 사유는, 재정, 건강 등 개인적인 사유이며, 지난 몇년간 레이븐 커뮤니티의 호응과 지지에 감사하다고 말했다.


□ 개인 논평

  ㅇ 레이븐의 비전(feat. 사토시 비전)
    - 사토시 나카모토는 비트코인을 출시한지 얼마 지나지 않은 2009년 2월 온라인 포럼을 통해 비트코인이라는 오픈소스 P2P 전자화폐 시스템을 개발하였고, 이는 중앙서버와 신뢰기관 없이 완전 탈중앙화되어있다고 밝혔다.
< http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source >
    - 그로부터 9년후, 비트코인 출시 9주년을 기념하여 레이븐이 출시되었다. 단순 재미로 9주년을 기념한것이 아니고, 레이븐은 탈중앙성을 사수하기 위해 X16R이라는 알고리듬을 탑재하였고 특정 운영주체를 두지 않았다. X16R에 대한 알고리듬은 필자가 이미 충분히 설명하였기에 넘어가지만 특정 운영주체를 두지 않은 점에 대해서 얘기하겠다. 혹시 당신이 '비트코인처럼 레이븐이 특정 운영주체가 없을때 갖는 이점이 무엇인가요'라는 질문을 받을때 '누구나 참여할수 있고 개발할수 있으며, 한명 또는 소수의 의사결정에 따라 좌지우지 되는 리스크(오너리스크)가 없다'라고 말한다면 절반만 알고 있는것이다. 정답은 아니지만 또다른 이점을 말하자면, '특정 운영주체가 없는 것은 곧 정부나 당국의 검열로부터 자유롭기 때문에 네트워크가 지속가능'하며, 이는 특정 운영주체에 의해 운영되는 거래소나 프로젝트들이 정부나 당국에 의해 엄격하게 규제를 받는 작금의 시점에 매우 현실적인 이점이다.
    - 그런 비트코인과 레이븐의 비전에 ASIC이라는 만만치 않은 장애물이 지금 나타났다. 2013년 초 최초의 양산용 ASIC이 출시된 이래 작업증명 기반의 수많은 네트워크가 ASIC에 의해 지배당하거나 ASIC을 저항하기 위해 고군분투 중이며 비트코인, 이더리움, 레이븐도 그 예외가 아니다. 레이븐에게 있어 ASIC 저항을 더욱 중요한 이유는, ASIC을 사전에 차단하기 위해 독자적인 알고리듬으로 시작하였고 처음부터 지속가능한 탈중앙성을 커뮤니티에게 약속했기 때문이다. 그렇기 때문에 레이븐 개발자들은 그 약속과 커뮤니티 의견을 바탕으로 ASIC을 막기위한 포크를 이행하려고 한다.
    - 하지만 필자가 지어낸 말 중에 '커뮤티니보다 위대한 개발자는 없다'라는 말이 있다. 인류 역사를 돌이켜보더라도 혁신(혁명)의 성공여부는, 그 혁신(혁명)의 우수성보다 커뮤니티(민중)의 지지를 얼마나 받아내느냐가 관건이고, 올바르지 못한 기득권세력(상류층)은 그 지지기반인 커뮤니티(민중)를 의도했든 아니든 분열(멸망)시키는 법이다. 따라서 커뮤니티는 개발자, 거래소 등이 그 프로젝트의 비전을 지킬수 있도록 때론 비판도 하고 때론 압박도 해야한다. 아래는 10월 1일 채굴풀과 거래소의 알고리듬 변경 참여여부를 보여주는 사진이다. 우리 고유의 레이븐 비전을 위해서, 지켜보고 생각하고 행동하자.
< 10월 1일 업데이트 참여여부(9월 1일 기준) >

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

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

#69 Devs Meeting Review(23 Aug 2019)

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



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
     - Mid-September(Not fixed): Testnet HF
     - October 16(Wed) Mainnet HF(=Istanbul HF) *May be delayed.


□ Istanbul HF-related client update

  ㅇ Whether to merge Istanbu lHF-related EIP by clients
    - (Pantheon) All EIPs have been merged and merge status by EIP/Client has been created here.
    - (Geth) All EIPs have been merged and implemented.
    - (Aleth) EIP-1108, 1344, 2028 have been merged, but EIP-1884, 2200 is still open.
    - (Parity) EIP-2028 is merged, EIP-1344, 2200 is open but has not yet been implemented, and EIP-1108 is closed.
    - (Trinity) EIP-1108, 2200 have been merged, and EIP-1344, 1884, 2028 are open.
    - (Nethermind) All but one EIP have been merged and will soon be merged.


□ Istanbul Testnet HF Block Number Decision

  ㅇClient updates and mainnet HF schedule
    - Since not all clients, including Parity, have yet to complete the merging and implementation of all EIPs,  it is not immediately possible to determine the Testnet HF block number, so it is necessary to have a devs meeting  next week or decide via gitter. That way we can discuss how much more time we need, or reevaluate (on EIP, etc.).

    - If we discuss the testnet HF block number again at the end of August, it will be mid-September when Parity is ready and mainnet HF scheduled for October may not be available.

    - There is one issue related to Testnet HF and Mainnet HF, and if this is not resolved, it is necessary to mention it because it may delay Mainnet HF. As of the cost of gas, it may be necessary to raise the cost of gas to prevent some contracts from being interrupted. In fact, Martin concluded that it could potentially occur. According to his analysis, in some cases, gas charges can soar or fixed gas costs are consumed for a call. However, there is no permanent solution to this problem, so once HF hapens, we can find a solution based on the case that contracts actually stop.

    - But the problems is that contracts would be stopped and not be implemented properly, and then something like Parity multisig incident could happen, and there may be no chance to modify or add function in the future.

    - But as for the gas price fluctuations, so far no one has ever thought it would be a problem and no one has fixed it. We can upgrade to solve the gas problem, but then we can have a completely different kind of problem. We have to work it out before we set testnet HF block number, but in order to have a criteria, we have to make a formal proposal like EIP, which should be a less likely to be hacked or more certain way to proceed. Only then can the debate be led to a technical level and how best to deal with such concerns. That's what it means. It's the kind of community that's worried about it. In that sense, we need to listen to the participants who have such concerns in the community and think more about whether we need to find a clear solution before testnet HF.


□ Decision issues on previous devs meeting

  ㅇ Clients and EIPs
    - All clients have decided that all EIPs for Istanbul HF should be implemented by August 23, but this has been delayed to September 6, so we will not set a testnet HF block number right now.

  ㅇ Mainnet HF Schedule
    - Although it is still difficult to determine, Mainnet HF schedulemay be postponed to November, given that it should take at least a month from testnet HF.

※ 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.



□ Personal Comments

  ㅇInform the Ethereian
    - As mentioned in the meeting, the Istanbul HF is likely to be postponed following the last Constantinople HF. Some may be very disappointed by the news, and community like Reddit complaind about it. There are concerns and criticisms that Parity (21%), which is the second most important client of Ethereum, is still not even merging EIP, rather than implementing it. In February, I wrote and shared the article "2019 Etherium Selection, Splited or Growing"(click here). The point of the article is that they often show a mysterious way of contributing to Ethereum, whether it's an alliance or enemy.

    - Anyway, this trip to Istanbul will be delayed a little bit. In fact, such delays may be considered good or bad from the perspective of devs, investors, and so on, but there is no great dissatisfaction with the delay in itself. Because I do know why it is being postponed. Even at this meeting, a dev raised questions about gas charges (simple verbal offers to raise related gas charges so that some calls could be interrupted), and there was a long discussion on whether to include this into testnet fork, and if the issue was an official proposal, such as EIP, and there was enough time to review and verify it, then testnet HF would have been delayed further.

    - In short, dev, especially core devs, think that it is better to postpone it to prevent accidents such as Constantinople Fork and Parity Multisig incident in the past, and I agree with that attitude.

    - As an analyst, Ethereum will wait and see to invest from the viewpoint of institutional investors who are extremely conservative in their investments, and it is not the time for us to invest either. In the course of time, Ethereum has become so big that it will take a lot of review, verification and time to easily change the arrangement, so often there will be long discussions, delays, and alternatives.

    - But as an investor, Ethereum is still attractive. Thanks to the steady research and development of Buterin and Vlad, who advocated the possibility of PoS, the time is slowly approaching to show the real face of Ethereum. There are already too many allies and foes for Ethereum's color to die. In other words, there is so much interest of it. If EEA(Enterprise Ethereum Alliance) and Deapps are successful, Ethereum will thrive, and even if Ethereum Killers such as EOS suceed, it wouldn't be not so bad for Ethereum.

  ㅇInform the blockchainer
    - The greatest redistribution we will experience in the near future, thanks to the so-called Blockchain Revolution, will be the Redistribution of value, not the Redistribution of wealth. Wealth depends on how much money we have, but value depends on where and how we participate. That doesn't mean there will be a world where the rich suddenly become beggars and the poor become rich forever, but if the blockchain becomes popular, there will be a world where assets can be distributed in a more transparent and fair manner than the existing one.

    - So if someone says that cryptocurrency is expensive and useless, just say that the greatest redistribution, or redistribution of value, has already been shown by Bitcoin and Ethereum. I hope that all blockchain and cryptocurrency projects, including any other ethereum, will be developed

without losing their vision and initial focus, and that there will be good results as community participants have paid attention and invested in them.


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 구현 마감기한
     - 09월 중순(미정) : 테스트넷HF
     - 10월 16일(수) 메인넷HF(=이스탄불 HF) *지연될수도 있음

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

  ㅇ 클라이언트별 이스탄불HF 관련 EIP 병합 여부
    - (Pantheon) 모든 EIP를 병합하였고, EIP별/클라이언트별 병합 현황 사이트를 만들어봤다.https://notes.ethereum.org/@holiman/SyT_rGjNr
    - (Geth) 모든 EIP를 병합하였고 구현하였다.
    - (Aleth) EIP-1108, 1344, 2028는 병합하였으나, EIP-1884, 2200은 아직 열려있다.
    - (Parity) EIP-2028은 병합, EIP-1344, 2200은 열려있으며 아직 구현되지 않았으며 EIP-1108은 닫혀있다.
    - (Trinity) EIP-1108, 2200은 병합되었고, EIP-1344, 1884, 2028은 열려있다.
    - (Nethermind) 하나의 EIP를 제외하고 모두 병합하였으며, 곧 모두 병합할 것이다.


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

  ㅇ 클라이언트 업데이트와 메인넷HF 일정
    - Parity를 비롯하여 아직 모든 클라이언트가 모든 EIP의 병합 및 실행을 완료하지 않았기 때문에 당장 테스트넷HF 블록넘버를 결정할수 없으며, 따라서 다음주에 개발자 회의를 개최하거나 gitter를 통해 결정해야한다. 그렇게 해야 우리가 얼마나 많은 시간이 더 필요한지에 대해 논의하거나, (EIP 등에 대하여) 재평가를 할수 있을 것이다.
    - 그렇게 8월말에 다시 테스트넷HF 블록넘버를 논의한다면, Parity가 준비되었을때는 9월 중순이 될것이며 10월에 예정되어있는 메인넷HF가 불가능할수도 있다.
    - 테스트넷HF와 메인넷HF와 관련된 사안이 하나 있는데, 이것이 해결되지 않으면 메인넷HF를 지연할 수 있기 때문에 언급할 필요가 있다. 가스비와 관련된 것으로, 일부 컨트렉트가 중단되지 않도록 가스비를 올려야할수도 있다. 실제로 그럴 가능성에 대한 분석은 개발자 Martin에 의해 수행되었으며, 잠재적으로 발생할수 있다는 분석 결론이 있었다. 분석에 따르면, 어떤 경우에 특정 호출에 대하여 가스비가 치솟을때도 있고 고정된 가스비가 소비될때도 있다. 하지만 이런 문제를 영원히 해결할수 있는 해결책은 없으므로, 일단 이대로 HF를 추진하되 실제로 컨트렉이 중단된 경우를 바탕으로 해결책을 찾을수도 있다.
    - 하지만 정말 걱정되는건 잠재적인 문제로 인하여 컨트렉이 중단되어 제대로 이행되지 않았는데, 그걸 (강제로) 풀다가 과거의 Parity Multisig와 같은 사태가 발생할수 있으며, 그렇게 된다면 앞으로 수정하거나 기능을 추가할 기회가 없을수도 있다.
    - 다만 우리가 지금 말하고 있는 가스비 변동에 대해서는, 여태껏 누구든지 이것이 문제가 될거라고 생각하지 않았고 따라서 아무도 그것을 고치지 않았다. 가스비 문제 해결을 위해 업그레이드를 할수도 있지만 그 다음에는 완전 다른 종류의 문제가 발생할수도 있다. 테스트넷HF 블록넘버를 정하기 전에 해결해야 하지만 기준을 갖기 위해서 EIP와 같은 공식적인 제안서를 작성해야하며, 그것은 해킹될 여지가 덜 하거나 더 확실한 방법이어야 합니다. 그렇게 해야만 기술적인 수준으로 논의가 이어질수 있고, 그런 고민을 어떻게 최선의 방법으로 다룰수 있는지 알수 있을것이다. 그런의미에서 커뮤니티안에서 그런 고민을 갖고 있는
참여자들에게 귀 기울여야하며 테스트넷HF 이전에 확실한 해결책을 찾아야하는지에 대해서는 좀 더 생각해볼 필요가 있다.


□ 이전 개발자 회의 결정 사안

  ㅇ 클라이언트의 EIP
    - 모든 클라이언트가 8월 23일까지 이스탄불HF에 대한 EIP를 모두 구현해야한다고 정하였지만 이는 9월 6일로 지연되었으며, 따라서 테스트넷HF 블록넘버는 정하지 않겠다.

  ㅇ 메인넷 HF 일정
    - 아직 단정짓긴 어렵지만, 테스트넷HF 일정이 정해진 이후에 메인넷HF 연기를 비롯한 일정을 정할 수 있을것이며 테스트넷HF로부터 최소한 한달 이상의 시간을 가져야한다고 볼때 11월로 연기될수도 있다.


  ※ 이스탄불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에 이어 이번 이스탄불HF도 연기될 가능성이 높아졌다. 이 소식에 매우 아쉬워하는 이도 있겠지만, 그 연기의 이유에 대해서 레딧 등 해외 이더리안들에 대한 성토가 이어지고 있다. 이더리움 클라이언트 중에서 Geth(76%) 다음으로 비중이 높은 Parity(21%)가 여전히 이스탄불HF 반영 확정 EIP를 구현은 커녕 병합조차 하고 있지 않는 상태에 대한 우려와 비판이 있다. 필자는 지난 2월 '2019 이더리움의 선택, 분열인가 성장인가'(여기 클릭)이라는 글을 작성하여 공유한적이 있다. 해당 글과 이번 논평 일부를 차지하고 있는 Parity에 대한 요지는 이들이 이더리움에 기여한 바는 크나 종종 아군인지 적군인지 알수없는 행태를 보인다는 점이다. 여기서 더 나아가면 오해의 소지가 있을까봐 함구하겠지만 신경이 쓰이는 건 어쩔수 없다.
    - 여튼 이번 이스탄불로 가는 여정은 조금 미뤄질것 같다. 사실, 하드포크(네트워크 업그레이드) 등이 연기되는 것은, 개발자, 투자자 등 관점에 따라서 좋게 또는 나쁘게 볼수 있겠지만, 개인적으로 연기되는 그 자체는 큰 불만이 없다. 왜냐면 연기되는 이유를 알기때문이다. 이번 회의의 경우에도, 한 개발자가 가스비에 대한 의문을 제기(일부 호출에 대해 컨트렉이 중단될수 있으므로, 그런 사태가 일어나지 않도록 관련 가스비를 올리자는 단순 구두상 제안)하였고 이걸 테스트넷 포크부터 고민하여 반영하냐 안하냐에 대한 긴 논의가 있었으며, 이 사안이 만약 EIP 등 공식적인 제안이었고 검토 및 검증할 시간이 충분했다면 테스트넷HF가 더욱 미뤄졌을것이다.
    - 간단히 말해, 개발자, 특히 코어 개발자 입장에서는 어설프게 준비하다가 과거 콘스탄티노플 포크때나 패리티 멀티시그 사태 같은 사고가 날 바에야 연기하는게 낫다고 생각하고 필자 역시 그 점에는 공감하고 있다.
    - 분석가로써 볼때, 이더리움은 투자에 지극히 보수적인 성향을 가진 기관투자자 입장에서는 관망할 것이며, 필자 역시 냅다 지를 타이밍은 아니라는 입장이다. 그간 이더리움이 성장하는 과정에서 그것이 보여준 혁신만큼이나 너무 커버려 합의방식 등을 쉽게 바꾸기에는 많은 검토, 검증, 시간이 필요할 것이며, 그래서 종종 긴 논의와 연기, 대안 등이 나타는 것이다.
    - 그런데 투자자로서 볼때, 이더리움은 여전히 매력적이다. 일찌기 지분증명방식(PoS)의 가능성을 주창한 부테린 군과 블라드 등의 꾸준한 연구와 개발 덕분에 이더리움의 진면모를 보여줄 시기가 서서히 도래하고 있다. 이더리움의 색깔이 빛바래기에는 이미 너무 많은 아군과 적군이 있다. 달리말하면 그만큼 관심이 크다는 뜻이다. EEA(Enterprise Ethereum Alliance), 디앱(dApps) 등 아군들이 흥할수록 이더리움은 더욱 번성할거고, EOS 등 이더리움 킬러 등이 성공해도 모티브가 이더리움인만큼 이더리움에 결코 백프로 마이너스는 아닐것이다.

  ㅇ 블록체이너에게 고(告) 함
    - 우리가 소위 말하는 ‘블록체인혁명’ 덕분에 가까운 미래에 경험할 최고의 재분배는 '부의 재분배(Redistribution of wealth)'가 아닌 '가치의 재분배(Redistribution of value)'일 것이다. 부는 우리가 돈을 얼마나 갖고 있느냐에 달려있지만 가치는 우리가 얼마나 어디에 참여했는지에 달려있습니다. 그렇다고 부자들이 한순간 거지가 되고, 빈자들이 떼부자가 되는 세상이 오는 것은 아니지만, 블록체인이 대중화된다면 가치를 담는 유무형 자산들이 기존 세상보다 더욱 투명하고 공정한 방식으로 분배될 수 있는 세상이 온다는 말이다.
    - 따라서 누군가 암호화폐를 비싸기만 하고 쓸모없다고 말하거든, 그런 최고의 재분배, 즉 가치의 재분배의 가능성을 비트코인이더리움이 그만의 철학으로 이미 보여줬다고 답하면 된다(그래도 못 알아들으면 측은지심의 눈빛을 발산하길 바란다). 아무쪼록 이더리움을 포함한 모든 블록체인과 암호화폐 프로젝트가 비전과 초심을 잃지 않고 개발했으면 좋겠고 커뮤니티 참여자도 관심갖고 투자한 만큼 좋은 결과가 있기를 바란다.


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

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

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