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


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

[News] 이더리움 확장성과 채택 // Ethereum's scalabilty and adoption v1.0

Vitalik Buterin: Increasing Transaction Costs Risk Limiting Ethereum Adoption 

비탈릭 부테린: 트랜잭션 비용 증가는 이더리움 채택에 제한을 걸다

< 원문기사링크 https://www.coindesk.com/vitalik-buterin-increasing-transaction-costs-risk-limiting-ethereum-adoption >

□ Article contents(기사내용)

The increased cost of transacting on the ethereum blockchain is hurting the software’s adoption, says project creator Vitalik Buterin.
프로젝트 제작자 비탈릭 부테린은 이더리움 블록체인에서의 거래 비용이 증가하면서, 이 소프트웨어의 채택에 타격을 입히고 있다고 말한다.

Speaking with the Toronto Star this week, Buterin suggested projects that are considering whether to build on the technology will likely be butted out as the blockchain is overloaded with transactions, or in his words “almost full.”
(While a blockchain cannot ever be technically ‘full,’ Buterin’s comments indicate his current sentiment on the severity of the problem.)
부테린은 이번 주 토론토 스타와의 인터뷰에서, 이더리움 블록체인이 트랜잭션으로 꽉 차있거나 거의 꽉차있다는 이유로, 이더리움을 기반으로 구축할지 고려중인 프로젝트들은 존폐의 기로에 서게 될 수 있다고 말했다.
(블록체인은 기술적으로 꽉 찰수는 없지만 부테린의 발언은 문제의 심각성에 대한 그의 현재 감정을 보여준다.)

Still, Buterin’s comments speak to his understanding of the difficulties ahead for the project, with major planned upgrades including Ethereum 2.0 and a switch to proof-of-stake consensus ahead.
그러나 부테린의 발언은, 이더리움2.0을 포함한 계획된 주요 업그레이드와 향후 지분증명합의로 전환과 함께 이 프로젝트가 마주할 어려움을 반영하고 있다.

He told the newspaper:
“If you’re a bigger organization, the calculus is that if we join, it will not only be more full but we will be competing with everyone for transaction space. It’s already expensive and it will be even five times more expensive because of us. There is pressure keeping people from joining, but improvements in scalability can do a lot in improving that.”
그는 신문사의 인터뷰에서 이렇게 말했다.
"큰 기관이 들어올때, 그들은 이더리움 네트워크에 합류시 더 꽉 찰 뿐만 아니라 거래 공간을 놓고 모든 참여자들과 경쟁할거라고 생각할겁니다. 그렇지 않아도 이미 수수료가 높은데, 합류하면 우리때문에 심지어 5배 높을것이다. 이는 합류하는 것을 주저하게 만들고, 따라서 확장성 개선은 그런 문제 역시 개선시킬것이다.

Ethereum’s seven-day transaction fee average, a measure of demand on the network, actually sits at a 50-day low, falling since July 1 to sit around $0.11 ether per transaction currently.
이더리움의 주간 거래 수수료 평균은, 네트워크 수요의 척도로써, 실제로 7월 1일 이후 50일 동안 최저 수준으로, 현재 거래당 $0.11에 머물고 있다.
< Ethereum’s seven day mean transaction fee image via Coinmetrics
Coinmetrics를 통한 이더리움의 주간 평균 거래 수수료 이미지 >

Buterin, following past arguments and his current work, presented PoS as a potential solution to the problem, stating that altering transaction verification could lower fees by a factor of 100 per transaction, freeing space for organizations to build on the blockchain.
부테린은 과거의 주장과 그의 현재 작업에 이어, PoS를 잠재적인 해결책으로 제시하면서, 거래 검증을 변경하면 거래당 수수료를 100배까지 낮출 수 있으며, 집입 기관들이 블록체인에 구축할 공간을 확보할 수 있을거라고 말했다.

More broadly, the comments show how public adoption of ethereum is a growing concern. Earlier this month, the Enterprise Ethereum Alliance (EEA) appointed the Ethereum Foundation’s Aya Miyaguchi head of its Mainnet Initiative, a working group to connect enterprises with ethereum’s services.
넓게 보면, 그의 발언은 이더리움의 대중적 수용이 얼마나 큰 관심거리인지를 보여준다. 이달 초 이더리움기업연합(EEA)은 이더리움 재단의 미야구치 아야를 메인넷 이니셔티브 대표로 임명했다.

Discussing governance and adoption, Buterin said price volatility and cybersecurity remain leading issues as well. He concluded that the government has a role in regulating the space:
부테린은 거버넌스와 채택을 논의하면서, 가격 변동성과 사이버 보안도 여전히 중요한 이슈라고 말했다. 또한, 그는 정부가 공간을 규제하는데 큰 역할을 한다고 결론지었다.

“Governments do have a role and one of the roles in regulation. The usual concerns are about cryptocurrency exchanges where the basic idea is to do fundraising for a new project by directly selling tokens on the blockchains. There are debates whether specific kinds of ICOs [initial coin offerings] are legally categorized as securities.”
"정부의 역할 중 하나는 규제를 하는 것이며, 블록체인상에서 토큰을 직접 판매함으로써 새로운 프로젝트를 위해 자금조달을 하는 암호화폐 거래소에 대한 우려가 크다. ICO의 일부를 법적으로 증권으로 분류하는지에 대한 논란이 있다.

Buterin pointed toward low-risk uses of blockchain, such as identification of certifications, as adoption-leading technology.
아울러 부테린은 채택 선도 기술로써 인증 확인과 같은 위험부담 적은 블록체인 활용방안에 대해서도 언급했다.

□ Personal Comment(개인 논평)

 ㅇ깊어지는 이더리움 확장성 고민
    - 부테린 군이, 예전엔 단기 확장성 솔루션으로 영지식증명을 활용한다고 했다가 지난 7월에는 비트코인캐시 체인이나 이더리움 클래식 체인을 활용하자는 아이디어*를 낸걸 보고있자면, 이더리움 확장성 해소가 그만큼 시급하고 중요하다고 할것이다.
 ※ 관련글: https://ethresear.ch/t/bitcoin-cash-a-short-term-data-availability-layer-for-ethereum/5735
    - 여튼 기사내용 중, 부테린 군이 이더리움 체인이 현재 과부하 상태라 새로운 기관들이나 프로젝트들이 진입하기 어렵다고 지적하였고, 특히 이더리움 거래량이 거의 다 찼다고 말할정도로 현재 상황이 가볍지 않다는 뉘앙스를 풍겼다. 이 상황을 반전시킬수 있는 모멘텀은 아무래도 저 역시 최근 글들을 통해 강조한 '이더리움2.0'일것이다. 
    - 그런 관점에서 저 기사를 보며 필자는 2가지를 생각했다. 첫째로, (기사에서 PoS도입시 거래당 수수료가 100배 저렴해질거라고 했는데 왜 100배인지는 전 아직 모르겠지만) 유효성 검증과 투표, 그리고 거래처리속도가 왜 빨라지느냐에 대한 것이다. 우선 현재 이더리움 설계상으로는 벨리데이터(유효성 검증자)가 투표(검증자가 올바르다고 생각하는 블록에 메시징)마다 거래내역을 제출해야하기때문에 부하가 걸리고 결국 병목현상이 일상이 되는 등 체인의 확장성에 한계를 보여줬다. 그런데 이더리움2.0 설계상에서는 PoS메커니즘을 총괄하는 비콘체인 덕분에 EVM과 같은 실행머신이 없고(물론 eWasm이 대두되는 등의 이유도 있지만) 그런 머신을 사용하여 투표나 계산을 안해도 되니 그만큼 검증이 효율적이며 가스가 필요없게 된다. 뿐만아니라 일괄서명(aggregate signature)이라는 기법 덕분에, 모든 투표를 순서대로 긴시간동안 건건이 처리하지 않고, 심지어 오프체인상에서 충분히 모아질때, 즉 충분히 많은 검증자들이 지원하게될때(=스테이킹을 충분이 많이 하게될때), 체인에 전송 및 통합이 이뤄지고 이 과정을 보다 용이하게 만든다. 그덕에 비콘체인은 부하를 줄일수 있게 되고, 검증자들이 더 많이 참여하게 되며, 자연적으로 그만큼 탈중앙화되고 네트워크 보안도 올라가게 됩니다. 실제로 현재 이더리움 설계상에서는 벨리데이터 '참여'수가 최대 900정도에 불과하지만, 이더리움2.0설계에서는 그 '참여'수가 30만명도 커버가능하며, 시스템은 무려 최대 2^22(약 4백만)명까지 '지원'할수 있습니다. 이 2^22이라는 수치가 중요한 이유는 '시스템이 지원가능한 벨리데이터 수'가 클수록 '스테이킹할때 최소 이더수량'이 작아지기 때문이다. 가령 현재 이더 총 발행량이 2^27(약 1억 3천개, 실제론 1억 좀 넘음)이라하면 이더체인이 견딜수 있는 최대 오버헤드(초당 메시지)를 감안할때(이더측에서는 5천~6천정도 견딜수있을것으로 보고있음), 벨리데이터가 최대 2^22인데, '총 발행량/최대 벨리데이터'를 계산하면 2^5 즉 32ETH가 나오고 이게 바로 현재 계획상의 이더리움2.0에서 스테이킹할때 최소 이더수량이 나온다. 기사를 보며 생각한 두번째는, 이더리움 합의방식의 전환과 기관 진입입니다. 기사내용에서 부테린 군이 언급한 '기관 진입'이 '이더리움을 사용'할 기관 또는 프로젝트 추진 주체로 저 역시 해석했지만, 동시에 떠올린게 '이더를 매수'할 기관 또는 프로젝트 추진 주체였다. 제가 아는 소식통에 따르면 기관들이 이더매수에 다소 관망한다고 들었다. 왜 그런고 하니, 이더리움 행보가 투자하기에 애매하답니다. 확장성 해소도 문제지만, PoW에서 이더리움2.0에서의 PoW/PoS -> Full PoS까지 가는 여정이 너무 리스크가 크다는 것이다. 보통 여윳돈으로 코인에 투자하는 상대적으로 리버럴한 개인투자자들과는 달리, 우리가 생각하는 이상으로 보수 투자자들인 기관들은 '이더가 이더인건 알겠지만, 여튼 적극적일수는 없다'라는 것이다.
  - 항상은 아니지만, 유의미한 혁신은 변방에서 오기도 한다. 라이트 형제가 '사람을 날게하는 기이한 기구'라는 당시 획기적인 아이디어를 실행에 옮겼지만, 향후 수백명을 태울 보잉기나 레이더에 안 잡히는 스텔스를 생각하진 않았을겁니다. 마찬가지로, 부테린 등 이더리움 설립자들도 '월드컴퓨터'라는 현재로서는 원대한 컨셉을 잡긴했지만 어떻게 성공하거나 변질될지 모른다. 다만, 비행기가 다양한 기업들의 진입과 수많은 수요 덕분에 하나의 거대한 산업과 대중적 수용을 이룬것처럼, 이더리움도 체질개선 잘 하고 특이점만 넘으면 산업표준은 물론 인류사회의 한 페이지를 장식할수도 있다. 그런데 아직은 그 꿈의 궁전은 요원하고, 거길 가려고 해도 수많은 하드포크와 이더리움2.0이라는 큰 변곡점을 앞두고 있다.


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

[Ethereum] '제68차 이더리움 개발자 회의' 분석 및 개인 논평(8월 16일) v1.0

#68 Devs Meeting Review(16 Aug 2019)

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



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

□ Roadmap(https://eips.ethereum.org/EIPS/eip-1679) 

   <Istanbul HF Roadmap>
     - May 17(Fri): hard deadline to accept proposals for “Istanbul”
     - July 19(Fri): soft deadline for major client implementations
     - Aug 14(Wed): projected date for testnet network upgrade(Ropsten, Gorli, or ad-hoc testnet) Delayed due to EIP implementation and testing
     - Mid-September(Not fixed): Testnet fork
     - Oct 8 to 11: DevCon5, Osaka Japan
     - Oct 16(Wed) Initial projected date for mainnet upgrade(“Istanbul”)

□ Related to the EIPs for Istanbul HF

  ㅇIstanbulHF client update for EIPs allowed
    - (Nethermind) We only got EIP-1344, but didn't have EIP-152, 1108, 2028, 1884, 2200.
    - (Geth) We got EIP-1344, 1108, 2028, 1884, but didn't have EIP-152, 2200.
      * Other clients are absent.

  ㅇDecision about tentative EIPs
    - EIP-2200 and EIP-1884 will be included to Istanbul HF as they are judged to have reached an agreement without disagreement.

□ Conformance testing

  ㅇSpace for testing, Gitter channel and ReTestEth
    - EIPs to be included in HF must be tested, and the tests should be performed by EIP proposer or champion. However, sometimes proposers or champions are too motivated to know how to test what kind of test is required and in this case, other devs may suggest a way to facilitate the test. To do this, we will be able to test it through multiple clients on Gitter channel or ReTestEth.

□ Upgrading testnet and follow-up steps to Istanbul HF

  ㅇSeptember 4(Wed) of testnet HF block number 
    - We have just decided on the EIPs to be included in Istanbul HF but Parity is not present at the meeting, so we cannot decide testnet HF block number, which will be determined at next meeting (or through Gitter).
    - All clients should be prepared to execute all EIPs to be included in Istanbul HF by August 23(Fri) when the next meeting will be held.

  ㅇIstanbul HF conducted twice.
    - We will do Istanbul HF twice because there are EIPs we want but can't include in Istanbul HF such as EIP-1057 (or ProgPoW), but are not yet ready.

□ HF at once or separately

  ㅇAt once
    - By placing the prepared EIPs in the pool and implementing multiple EIPs at once, the plan can be established at the expected time intervals and there are chances for controling the HF issues.  However, EIPs proposers may be in a hurry due to the HF review deadline.

  ㅇSeparately
    - When fully prepared, EIP can be proposed and individual HF can be done. However, it will be messy as a number of seperate HFs are needed.

  ㅇ Fundamental issue
    - It is important to do HF at once or seperately, but a more important thing is that not much consideration is made until EIPs are implemented for HF. In fact, no one monitors the EIPs and no one pays attention at the last check. Therefore, clients should accept the proposed EIPs from the beginning, but attend the meeting to assess their progress.
    - Another concern is that before someone proposes an EIP and builds, and executes it, clients seem to know whether it's good or bad.
    - The problem with the EIP process is that the overall process cannot be tracked, and to solve it, the EIP progress is visually expressed so that many parties can know when to look at the EIP. To monitor progress from a client perspective, it is also good to use a dashboard.
    - Everything just discussed seems reasonable, and we don't have to decide immediately how to do it, but we'll discuss it further.

□ Naming HF

  ㅇ After Istanbul HF
    - Naming the HF was an old debate that began in April, and was re-discussed after two rounds of Istanbul HF. Second Istanbul HF is called by a different name besides Istanbul HF 2.
    - The HF after Istanbul HF will be named after the city where Devcon was held(e.g., Istanbul HF 2 will be Berlin HF where Devcon 0 was held).

※ 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

  ㅇEthereum's rate of issuance and return
    - In a personal comment to the 67th Ethereum Devs meeting, I explained about Ethereum 2.0. If you are an Ether investor, perhaps the most interesting thing in Ethereum 2.0 is the conversion of consensus protocols from PoW to PoS, especially funding deposits, validation, or staking.
    - But there is a thing associated with this stake, which is the issue rate. You will all know that adjusting the supply of one asset changes its value(assuming that other factors such as demand, are the same). However, it must also be known that network security and liquidity are very much related to such supply and value.
    - In order to learn more about these Ether monetary policies, we will look at the trend of Ether's issuance through photos below.
< the trend of ether issuance(orange) & volume(blue)(https://medium.com/ethhub) > 
  - Ether has shown rapid fluctuations in the issuance rate of major events such as difficulty bombs, major HFs, and the phase 2 of ethereum2.0(shard-chain). Such a trend in the rate of issuance is increasingly declining, and the total volume of issuance is rounded to a smooth curve. The most ideal aspect of the Ethereum network here would be the network's security with a lower issuance rate. However, if the issuance rate is to be low, there must be fewer validators to increase network security.
< ether issuance & staking rate in Ethereum2.0(https://docs.ethhub) >
    - In the picture above, a security risk is large because the lower the number of staked ether used for validation, the smaller the issuance rate, but the higher the chances that a few whales will control the network.
    - Of course, all of these analyses do not take into account the following variables: The first variable is the price of ether. As you know, the price volatility of cryptocurrency is very big, which can have a significant impact on the price-based staking rate. The second variable is the 'architectural factor of Ethereum 2.0. To date, it has been found that it is not possible to transfer ether between the chain and the existing PoW chain until phase 2(2020) of Ethereum2.0. In other words, when beconchain is introduced and validation is initiated in early 2020, if you migrate to a new version of ether and then stake it, the staked ether cannot be moved to the exchange or cashed until the shard-to-shade transmission is available in 2021(as is now known, you can transfer another validator). The third variable is "investment sentiment", which is a more fundamental variable than the aforementioned first and second variables and is about whether ether investors hold Ether. In other words, if ether's investment is strong, investors will not only hold but also stake ether, and if it is not strong, they will sell or invest in other coins.
    - I've talked about it in a complicated way, but it's simple. Keep an eye on ethereum, study and invest. To give you a simple hint for that, Devcon5 and IstanbulHF in October, Ethereum 2.0 Phase 0 and another HF in early 2020 are coming. What if ether is listed on BAKKT by the end of the year after Bitcoin?
   - But it's not only wishful thinking that these big events will bring about ether to the moon, but also keep in mind that each time it comes with enormous risks. Still, if our lives consist of a block of "decisions at moments" and a chain of "responsibilities for that decisions", I hope that your own blockchain will be a success project.


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일(금) : 주요 클라이언트 실행 마감기한
     - 09월 04일(수) 테스트넷에서의 네트워크 업그레이드*(Ropsten, Gorli, 또는 다른 임시 테스트넷)
      * 19.1월 비탈릭이 포크 대신 네트워크 업그레이드라고 부르고, 체인분기가 일어나는 경우만 하드포크라고 부르기를 이더리움 커뮤니티에 제안한 바 있음.
     -10월 16일(수) 메인넷에서의 네트워크 업그레이트(=이스탄불 HF)

□ 이스탄불HF 관련 EIP 관련

  ㅇ 이스탄불HF 허용(+잠정보류) EIP에 대한 클라이언트 업데이트
    - (Nethermind) 우리는 EIP-1344만 실행하였고, EIP-152, 1108, 2028, 1884, 2200은 아직 실행하지 않았습니다.
    - (Geth) EIP-1344, 1108, 2028, 1884를 실행하였고, EIP-152, 2200은 아직 실행하지 않았습니다.
      * 그 외 클라이언트는 불출석 등으로 언급이 되지 않았음

  ㅇ 잠정보류된 EIP에 대한 결정
    - EIP-2200과 EIP-1884은 이견없는 합의가 이루어졌다고 판단되므로 이스탄불HF에 허용될 예정이다.

□ 적합성 테스트

  ㅇ 테스트를 위한 공간, Gitter channel과 ReTestEth
    - HF에 포함될 EIP는 테스트가 반드시 행해져야하며, 그 테스트는 EIP제안자나 담당자가 수행하여야 한다. 다만, 제안자나 담당자가 의욕이 넘쳐도 어떤 테스트가 필요하는지 어떻게 그 테스트를 할수 있는지 모를때가 있는데, 이럴경우에는 다른 개발자들이 그 테스트를 용이하게 할 방법을 제시할수 있다. 이를 위해서 Gitter channel이나 ReTestEth와 같은 것을 통해 테스트를 하면 여러 클라이언트를 통해 테스트를 할수 있을것이다.

□ 테스트넷 업그레이드 및 이스탄불HF 후속 단계

  ㅇ 9월 4일(수) 테스트넷HF의 블록넘버 
    - 이제 막 이스탄불HF에 포함될 EIP를 정했고 Parity측이 회의에 참석하지 않은 관계로 우리는 테스트넷HF 블록넘버를 정할수 없으며, 그 블록넘버는 다음 개발자 회의에(또는 Gitter를 통해) 결정될것이다.
    - 이에 모든 클라이언트들은 다음 개발자 회의가 열리는 8월 23일(금)까지 이스탄불HF에 포함될 모든 EIP를 실행할수 있도록 준비하기를 바란다.

  ㅇ 이스탄불HF를 두번에 걸쳐 실시
    - 우리는 EIP-1057(또는 ProgPoW)와 같이 이스탄불HF에 포함시키고 싶지만 아직 준비가 되지 않은 EIP가 있기때문에 이스탄불HF를 부득이하게 두번에 걸쳐 실시할 예정이다.

□ HF를 모아서 할것인가 여러개로 나눠서 할것인가

  ㅇ 모아서 HF하기
    - HF가 준비된 EIP를 풀에 대기시켜 여러 EIP를 한번에 구현함으로써 예상가능한 시간간격대로 계획을 수립할수 있으며 HF와 관련된 사안들을 더욱 컨트롤할수 있는 여지가 있다. 다만 HF 검토 기한에 쫓겨 EIP담당자들이 다소 서두를수 있다.

  ㅇ 나눠서 HF하기
    - 충분히 준비가 되었을때 EIP를 제안하고 개별HF를 추진할수 있다. 다만, 수많은 개별HF를 추진해야하므로 그 과정에서 혼선이 발생할수 있다.

  ㅇ 근본적인 문제 
    - 모아서 또는 나눠서 HF를 하는것도 중요하지만, 더 중요한 문제는 EIP가 HF로 구현될때까지 많은 검토가 이루어지지 않는다는 점이다. 실제로 아무도 EIP를 모니터링하지 않으며 마지막 점검시 아무도 주의를 기울이지 않는다는 것이다. 따라서 클라이언트들은 초반부터 제안된EIP를 받아들이되 회의에 참석하여 그 EIP진행여부를 따져봐야한다.
    - 또다른 걱정거리는 누군가 EIP를 제안하고 그것에 대해 구축, 실행, 실행하기도 전에 클라이언트들로 하여금 그게 좋은건지 나쁜건지 파악해달라는 듯 하는 태도다.
    - EIP 프로세스의 문제점은 전체적인 프로세스를 추적할수 없다는 점이며, 그것을 타개하기 위하여 EIP진행상황을 시각적으로 표현하여 많은 당사자가 언제 EIP를 살펴봐야하는지 알수있게 하는 것이다. 클라이언트 관점에서 진행상황을 모니터링하기 위해서는 대시보드를 활용하는 것도 좋다.
    - 방금 논의된 것들은 모두 합리적으로 보이며, 어떻게 해야하는지 당장 결정할 필요는 없지만 더 논의하기로 한다.

□ HF 이름 짓기

  ㅇ 이스탄불HF 이후의 HF
    - HF 이름을 지어내는것은 지난 4월부터 시작된 오래된 토론 안건으로, 이스탄불HF가 두 차례에 걸쳐 실시되어 다시 논의하게 되었다. 2번째 이스탄불HF는 이스탄불HF 2 외에 다른 이름으로 불리는게 어떤가.
    - 이스탄불HF이후의 HF는 데브콘이 열린 도시의 이름을 따서 명명하기로 한다(가령 이스탄불HF 2는 데브콘0이 개최된 베를린HF로 하는식)


  ※ 이스탄불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에서의 SATICCAL opcode보다 작업비용이 더 저렴.
     6) EIP-1985 : 가스제한, 블록넘버 등 EVM 매개변수들에 대한 적정 한계범위를 적용한다. 명시적인 범위를 적용하면 호환가능한 클라이언트를 구현하는데 용이함.
     7) EIP-2045 : 이더리움 거래량(확장성)을 높이기 위하여 Computational opcode의 가스비를 줄여서 별도의 서브루틴 도입없이 또 점프작동방식을 변경없이 속도를 향상함.
     8) EIP-2046 : 프리컴파일에 대한 정적호출의 가스비를 줄임으로서, 파일사용이 보다 효율적.


□ 개인 논평

  ㅇ 이더리움 발행률과 수익률
    - 지난 67차 이더리움 개발자 회의의 개인 논평에서 필자는 이더리움2.0에 대하여 설명하였다. 만약 당신이 이더 투자자라면 이더리움2.0에서 가장 관심있는 사안은 아마도 PoW에서 PoS로의 합의프로토콜 전환일것이고, 그중에서도 자금 예치 및 유효성 검증, 즉 스테이킹에 대한 관심이 클 것이다.
    - 그런데 이 스테이킹과 연관된 요인이 있으니 바로 '발행률'이다. 한 자산의 공급을 조절하면 (수요 등 다른 요인은 동일하다는 전제하에) 그에 따른 가치가 변한다는 것은 다 알것이다. 다만 네트워크에서는 그런 공급과 가치에 따라 네트워크 보안과 유동성에도 매우 큰 관련이 있다는 점도 반드시 알아야 한다.
    - 이러한 이더의 통화정책을 좀 더 알아보기위하여 이더의 발행 추이를 사진을 통해 알아보겠다.
< 이더 발행률(주황색)과 발행량(파랑색)의 추이(https://medium.com/ethhub) >

    - 이더는 난이도 폭탄, 주요HF, 이더리움2.0의 2단계(샤드체인도입) 등 굵직굵직한 이벤트마다 급격한 발행률 변동을 보이고 있다. 그런 발행률 추세는 점점 더 발행이 줄어드는 추세를 보이고 있으며, 그럴때마다 총 발행량은 원만한 곡선을 보이고 있다. 여기서 이더리움 네트워크의 가장 이상적인 모습은, 보다 낮은 발행률을 보이면서도 네트워크 보안성을 높은 상태일것이다. 그런데 발행률이 낮으려면 그만큼 유효성 검증자가 적어야하는데, 네트워크 보안성이 높아지려면 유효성 검증자가 많아야한다.

< 이더리움2.0에서의 이더발행과 스테이킹이율(https://docs.ethhub.io) >

    - 바로 위의 사진에서 보면, 유효성 검증에 활용되는, 즉 스테이킹된 이더가 적을수록 발행률은 작지만 소수의 고래들이 네트워크를 컨트롤할 확률이 높아지기에 보안리스크는 크다고 볼 수 있다.
    - 물론 이 모든 분석이 다음과 같은 변수들은 고려하지 않은 것이다. 첫째 변수는 '이더의 가격'이다. 아시다시피 암호화폐의 가격 변동성은 매우 큰 편으로 가격에 따른 스테이킹비율에도 적지 않은 영향이 있을수 있다. 둘째 변수는 '이더리움2.0의 구조적 요인'이다. 현재까지 밝혀진바로는, 이더리움2.0의 0단계(2020년 초)에서 2단계(2021년)까지는 체인안팎, 즉 기존PoW체인과 비콘체인 간 이더의 쌍방향 전송이 불가하다. 다시 말해, 2020년 초에 비콘체인이 도입되어 유효성 검증이 개시될때, 당신이 새로운 버전의 이더로 마이그레이션 후 스테이킹 할 경우 그 스테이킹한 이더는 2021년 샤드간 전송이 가능할때까지 거래소로 옮길수도 현금화 시킬수 없다(현재까지 알려진 바로는 다른 검증자에게 전송가능하다). 셋째 변수는 '투자자 심리'다. 앞서 말한 첫째, 둘째 변수보다 더욱 근본적인 변수로, 이더 투자자가 이더를 갖고있을것인가에 대한 사안이다. 즉, 이더의 투자성이 크다고 하면 홀딩은 물론 스테이킹까지 할것이며 투자성이 적다고 하면 이더 발행률과 수익률과는 무관한 현금화, 타 코인 투자 등을 선택할것이다.
    - 뭐 복잡하게 얘기했지만, 간단하다. 주시하고 공부하고 투자하라. 그것을 위하여 간단명료한 힌트를 드리자면, 10월에 있을 Devcon5이스탄불HF, 2020년 초에 있을 이더리움2.0 0단계또다른 HF가 우리를 기다리고 있다. 혹시 아나, 비트코인 다음으로 이더리움이 BAKKT에 연내 상장될지(이 글이 성지가 되길).
    - 하지만 이런 큰 이벤트들이 이더의 떡상을 부른다는 것은 희망사항일뿐, 그때마다 엄청난 리스크가 동반된다는 사실도 명심하길 바란다. 그럼에도, 우리의 인생이 '매순간의 결정이라는 블록''그 결정에 따른 책임이라는 체인'으로 구성되어있다고 한다면, 당신만의 그 '블록체인'이 꼭 성공하는 프로젝트가 되길 바라면서 이번 논평을 마치겠다.


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


<Reference>
 1) https://medium.com/ethhub/the-basics-of-ethereum-2-0-economics-3bd2ffc7fd0e
 2) https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-economics

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

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


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

□ Analysis of the meeting by subject

  ㅇ ASIC mining machine launch and how to beat ASIC mining
    - ASIC mining machine has been released and is already being sold through some sites. The machines on sale are as follows.

    - When changing Raven algorithm, devs discussed time frame from one week to eight weeks. And when deciding to change the algorithm, it will be mandatory change rather than community voting.
    - Tron Black(Tron) said the ASIC miners on sale are only 30% more efficient than GPUs, although they are cheap, and do not make a big difference (in terms of hash power and centralization) and therefore do not have a big threat. However, he said that the machines need a response. He also said he has an idea that will make GPU miners happy, and that a detailed change will be unveiled on Monday.
    - The existence of ASIC mining is against Raven's philosophy as stated in its White Paper, so devs will try to resist ASIC mining.
    - Tron said the proposed change would be small, and the so-called x16r2 would retain 16 sub-algorithms but could change rotation. However, he said that it would resist the current ASICs but not new ASICs. And this economics of the race is in our favor because of the cost of making ASICs that will be obsolete. The biggest risk is when mining hash power of less than 50 percent did not participate in the upgrade. For this reason, he said, we should make sure that almost everyone participates in the change.
    - Other devs expected to upgrade legit mining pools such as supernova, minermore, ravenminer, nanopool and beepool, and said it was very important for exchanges to join the upgrade.
    - Monero's introduction of CNv4, an ASIC resistance algorithm, is another option, but devs are now looking for lighter changes, Tron said. The reason is that CNv4 is CPU-friendly and its CPU mining will on the rise because botnets (which means malicious software that is planted to use the computer without the knowledge of the computer's owner) could be a problem.
    - When asked by a dev what to do to prevent ASIC, Tron said that we need to resist ASICs (with a small change) as we promised and schedule them so that we do not conflict with the introduction of restricted asset functions. He also said that if ASICs become more dominant, devs will focus more on the timing of the change and in that case, we should ensure that exchanges upgrade as well.
    - A dev said another Raven(Raven Classic) coin could come out if a hard fork activate. Another dev said that there is someone who owns a mining farm of 1GH at 800W. Changing the algorithm will reveal whether this is ASICs or GPUs.


□ Personal Comment

  ㅇ ASIC issues again
    - There was a heated discussion of ASIC resistance during dev meeting on July 19. Then, four weeks later, we have seen another devs' discussions on ASIC resistance again because of the ASIC miners sold to the public.
    - I will explain once again now that some people still don't know the importance and reason for ASIC resistance (this cannot be stressed enough). ASIC mining is an unacceptable issue for the Raven project, and it has already promised ASIC resistance through its white paper. If ASIC mining is left unattended, a small number of ASIC miners will monopolize the hash power and control the economy and the operation rights, which could result in catastrophic damage to network maintenance and security. In other words, the decentralization of authority would be collapsed.
    - The advent of ASIC miners means that the prelude to undermining the value of decoupling centrality that we must uphold has been raised. Some may question whether ASICs can be prevented in advance. It is theoretically yes, but it is practically impossible. It's like having a new disease or virus come out and then getting rid of it or a vaccine to weaken it.
    - Therefore, devs are forced to quickly change its algorithms before new ASICs are mass-produced whenever ASICs appear. In addition, the change must be made by miners and exchanges on time to maintain network security and manage liquidity. If Raven, which follows the existing chain, uses the same name as Raven Classic and engages with some exchanges, things get complicated.
    - The problem isn't over here. Raven devs are currently testing major features such as restricted assets and dividends to be on the mainnet, and it is also very important to activate them quickly. Thus, as Tron said, algorithm changes and activations of key functions should not conflict with each other or one should not be ignored because of the other.

  ㅇ We don't have the royal road but our own answer.
    - As mentioned repeatedly, if ASIC resistance is a matter of 'survival' for Raven, the development is a matter of 'well-being'. The Raven devs and community may have to play a seesaw game of 'survival' and 'well-being' in the long-term.
    - There are not one or two projects that have already been slashed by ASICs, and Ethereum and Monero are also struggling to resist ASICs.
    - The community's role in this game, which may be tough, is very important. As anyone knows, Raven is a special project. I won't explain why and what it is special here because it's already known in other writings, but it would be a very sad if this great project collapsed in the adversity of ASICs. Therefore, we need to concern and support it.
    - I dare say it, considering that most of you are Raven investors. We are probably the ones who discovered the value of Raven too early and then put our money into it. That's why some now in the red and may be emotionally watching Raven's price. However, based on the rational judgment of the time when you decided to invest, I hope you understand Raven's ASIC resistance and development as much as you invested. In the process, I hope devs will be guided so that they don't get lost by supporting what we think is right and criticizing what we think wrong.
    - In the end, when Raven's potential becomes a reality, I really hope that you get good return than you have invested in it.

(한국어) 

□ 소재별 회의 내용

  ㅇ ASIC 채굴기 출시와 그에 대한 대응책 모색
    - ASIC 채굴기가 이미 출시되었고 사이트를 통해 이미 판매되고 있다. 그 판매중인 채굴기들은 다음과 같다.
    - 레이븐 알고리듬 변경시, 변경주기를 어떻게 설정해야하는지에 대한 논의가 있었고, 짧게는 1주일부터 길게는 8주까지 다양했다. 그리고 알고리듬 변경을 위한 결정을 할때, 커뮤니티에 의한 투표나 의견수렴보다는 강제적인 시행이 옳다는 의견이 더 많았다.
    - 트론블랙(이하 '트론')은 현재 판매중인 ASIC 채굴기는 저렴하기는 하지만, GPU보다 30%정도 더 효율적이라고 말하면서, (해시파워, 중앙화 측면에서) 큰 차이를 일으키지 않으며 따라서 큰 위협은 아니라고 말했다. 다만, 그에 대한 대응은 필요하다고 했다. 아울러 그는 GPU채굴자들을 행복하게 할 아이디어가 있다면서, 월요일에 세부적인 알고리듬 변경안이 공개될거라고 말했다.
    - ASIC채굴이 존재한다는 것은, 레이븐 백서에 명시된 레이븐의 철학에 위배되는 것이며, 따라서 개발자들은 ASIC채굴을 저항하는데 노력할것이라고 말했다.
    - 트론은 제안된 알고리듬 변경은 작을것이며, 이른바 x16r2라고 불리는 이 알고리듬은 서브알고리듬을 16개로 유지하되 로테이션을 바꿀수도 있다고 말했다. 다만, 그것은 현재의 ASIC채굴기를 저항시킬뿐, 향후 새로운 ASIC채굴기를 막진 않을거라고 했다. 그리고 (변경된 알고리듬에 의해) 쓸모없어질 ASIC 채굴기의 제작 비용때문에 이 경제싸움은 우리가 유리하다고 말했다. 가장 큰 리스크는 50%이하의 채굴 해시파워가 알고리듬 변경 업그레이드에 동참하지 않았을 때다. 이런 이유로, 그는 우리는 거의 모든이들이 알고리듬 변경에 참여하는 것을 확실하게 해야한다고 말했다.
    - 이에 다른 개발자들은 supernova, minermore, ravenminer, nanopool, beepool 등과 같은 합법적인 채굴풀들은 업그레이드 할것이라고 예상하였고, 거래소들이 업그레이드에 동참하는게 매우 중요하다고 말했다.
    - 일전에 모네로의 ASIC 저항 알고리듬인 CNv4 도입 역시 하나의 선택지지만 현재로서는 좀더 가벼운 변경안을 모색중이라고 트론은 말했다. 그 이유는 CNv4는 CPU친화적이라 CPU채굴이 늘어날텐데 그 경우 봇넷(필자주 : 컴퓨터 주인 몰래 그 컴퓨터를 사용하기 위해 심는 악성 소프트웨어를 의미)이 문제가 될수 있기 때문이라고 말했다.
    - ASIC을 막기위해 무엇을 해야하는지 묻는 한 개발자의 질문에, 트론은 작은 알고리듬 변경을 통해 우리가 약속한대로 ASIC을 무기력하게 만들어야하고 제한자산 기능 도입과 충돌하지 않도록 일정을 짜야한다고 말했다. 또한, 만약 ASIC이 더욱 지배력이 높아지면, (알고리듬 변경) 시점에 대해 더욱 집중할것이며, 그 경우 거래소들 역시 업그레이드 하도록 확실히 해둬야 한다고 말했다.
    - 한 개발자는 알고리듬 변경을 위한 하드포크를 할경우, 또 다른 레이븐(레이븐 클래식) 코인이 나올수 있다고 말했다. 또다른 개발자는 현재 800W에 1GH를 뽐내는 채굴농장의 소유자가 있다면서, 알고리듬 변경시 이것이 ASIC채굴인지 GPU채굴인지 드러날것이라고 말했다.

□ 개인 논평

  ㅇ 또다시 불거진 ASIC 이슈
    - 지난 7월 19일 개발자 회의때 ASIC저항에 대한 열띤 논의가 있었다. 그러부터 4주가 지난 현재, 우리는 대중에게 판매되는 ASIC채굴기때문에 또한번 ASIC저항에 대한 개발자들의 논의를 목격하였다.
    - 여전히 ASIC저항의 중요성과 당위성에 대하여 잘 모르는 분들이 있을까봐 다시한번 설명해드리겠다(이는 아무리 강조해도 부족하지 않다). 레이븐 프로젝트에 있어 ASIC채굴은 허용될수 없는 사안으로, 이미 백서를 통해 ASIC저항을 약속했다. 만약 ASIC채굴을 방치한다면, 소수의 ASIC채굴자들이 해시파워를 독식하면서 그들에 의해 경제권과 운영권이 좌우될것이고, 이는 네트워크 유지 및 보안에 치명적인 손상이 가해질수 있다. 즉, '권한의 분산'이라는 탈중앙성의 가치가 무너지는 것이다.
    - 본문에서 언급한 채굴기의 등장은 우리가 반드시 지켜야할 탈중앙성의 가치를 훼손할 서막이 올라갔다는 의미다. 혹자는 ASIC을 미리 막을수 없냐고 의문을 가질수 있다. 이론상 가능하지만, 실제로는 거의 불가능하다. 이는 마치 새로운 질병이나 바이러스가 나타난 뒤에 비로소 그것을 없애거나 약화시키는 의술이나 백신이 나오는 것과 같다.
    - 따라서 개발자들은 ASIC이 나타날때마다 새로운 ASIC채굴기가 양산되기 전에 그때그때 재빠르게 알고리듬을 변경할수밖에 없다. 또한, 그 변경을 채굴자들과 거래소들이 제때 업그레이드를 하여 네트워크 보안 유지 및 유동성 관리를 해야한다는 점이다. 이때 기존 체인을 따르는 레이븐코인이 '레이븐 클래식'같은 이름을 달고 일부 거래소와 결탁을 한다면 일은 복잡해진다.
    - 문제는 여기서 끝이 아니다. 우리에겐 현재 제한자산, 배당 등과 같은 주요 기능들이 메인넷에 올려지도록 테스트중인데 이 기능을 빨리 활성화하는 것도 매우 중요하다. 따라서 트론이 말한것처럼, 알고리듬 변경과 주요 기능의 활성화가 상호 충돌하거나 어느 하나가 다른 하나때문에 묻혀지면 안된다.

  ㅇ 왕도는 없지만 그만의 정답은 있다
    - 누차 언급한대로, 레이븐에게 있어 ASIC저항이 '생존'의 문제라면 개발상황은 '웰빙'의 문제다. 레이븐 개발자와 커뮤니티는 앞으로 기나긴 '생존'과 '웰빙'의 시소게임을 해야할지도 모른다.
    - 이미 ASIC에 난도질 당한 프로젝트는 한두개가 아니며, 그 유명한 이더리움과 모네로 역시 ASIC저항 이슈는 합의가 잘 안되는 안건들 중 하나이다.
    - 험난할지도 모르는 이 게임에 있어 커뮤니티의 역할은 절대적이다. 아는 사람은 알겠지만 레이븐은 특별한 프로젝트다. 왜 그리고 무엇이 특별한지는 다른 글들을 통해 이미 알려져있으므로 여기서 굳이 언급하지 않겠지만, 이런 특별한 프로젝트가 ASIC이라는 역경에 무너진다면 매우 안타까운 사건이 될것이다. 따라서 우리 커뮤니티의 관심과 지지가 필요하다.
    - 필자의 글을 읽는 대부분이 레이븐 투자자임을 감안하여 감히 말씀드린다. 우리는 어쩌면 너무 일찍 레이븐의 가치를 발견하고, 거기에 본인 자산을 투입한 사람들일지도 모른다. 그 탓에 현재 손실권에 들어갔고 따라서 감정적으로 레이븐을 지켜볼지도 모른다. 하지만 현재의 부정적인 감정은 조금 내려놓고 투자하기로 결심했던 당시의 이성적 판단에 따라, 적어도 투자한 만큼 레이븐의 ASIC저항과 개발상황을 숙지하기를 바란다. 그런 과정에서, 옳다고 생각하는 것에는 지지를 옳지 않다고 생각하는 것에는 비판을 하여 개발자들이 길을 잃지 않도록 길잡이가 되어줬으면 좋겠다.
    - 마지막으로, 향후 레이븐의 잠재력이 현실화될때, 당신이 레이븐에 관심을 갖고 투자한 것 이상으로 수익을 내기를 진심으로 바라면서 이번 논평을 마치겠다.


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

[Poem] 오감불만족(五感不滿足) v1.0

< 오감불만족(五感不滿足) >

 - 코인논객시인 오공


< Agony(괴로움) by Marcus Ortega(https://fineartamerica.com) >

나는 눈이 있어 괴롭다
쉼없이 등락하는 차트의 물결속에서
투자한 코인이 하락하는걸 보니 괴롭다

나는 귀가 있어 괴롭다

지인으로부터 투자성이 좋다는 소문을 듣고선
덜컥 사놓고 존버한 코인이 폭망해서 괴롭다

나는 냄새를 잘 맡아 괴롭다

남을 못 믿겠어서 스스로 공부하다가
대작나무 타는 냄새가 나서 샀더니 물려서 괴롭다

나는 맛에 예민해 괴롭다

몇번 당해보니 메이저코인이 최고같아서
입맛에 따라 사놨더니 비트코인만 상승해 괴롭다

나는 섬세한 촉각때문에 괴롭다

내 처참한 포트폴리오를 쳐다볼때마다
누가 안 건드려도 꼬집힌듯 고통을 느껴지니 괴롭다

이쯤되면 오감을 소유한 그 자체가 불만인 나는

다름아닌 오감불만족의 소유자 같다
그런데 남들이 모르는 나만의 감각, 육감이 있다

육감은 외부자극에 지배당하는 오감과는 달리

스스로 통제하고 관리할수 있는 나의 소중한 감각이다
다만 안타깝게도 너무 변화무쌍하다는 문제가 있다

때로는 희망회로에 불타 탐욕의 모습이 되기도 하고

때로는 현자타임이 와서 겸손의 모습이 되기도 한다

우리는 오감불만족인가 아니면 육감마저 불만족인가

하지만 그에 대한 진지한 고민을 하기는 커녕
오늘도 우리는 보고 듣고 맡고 맛보고 뜯기며 괴로워한다

[Ethereum] '제67차 이더리움 개발자 회의' 분석 및 개인 논평(8월 2일) v1.0




#67 Devs Meeting Review(2 Aug 2019)

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


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

□ EIPs related to Istanbul HF

  ㅇ Client update for Istanbul EIPs(+tentative EIPs)
    - At the last meeting, the upcoming HF opened the possibility that it could be carried out in October this year and early next year. In addition, Ethereum devs discussed EIPs that were clearly and tentatively accepted in Istanbul HF through the last meeting and decided to update each client on those EIPs.
    - (Pantheon) We did not implement EIP-1057(ProgPoW) or EIP-1962(Elliptic Curve), but we will implement it to meet the EIP specifications accepted or suspended in our development situation.
    - (Nethermind) We accepted EIP-1344 and EIP-2028 and excluded EIP-1057(ProgPoW) and EIP-1962(Elliptic Curve) is in progress. The rest of us are not starting soon or looking at it as important.
    - (Geth and Parity) The updates for these two clients are important, so we hope to implement them before the next meeting.

  ㅇ Tentatively accepted EIPs for Istanbul HF
    - We believe that EIP-2045(related to particle gas on EVM opcode)* will be tentatively accepted improvement. Without introducing other subroutines or changing the mode of jumps, we can expect to increase the speed (to resolve scalability). From the EWASM team's point of view, one of the potential benefits of EWASM is to speed up, so EIP-2045 on particle gas is a good alternative to EWASM. Optimizing compatibility between EVM and clients can be easier and faster than utilizing EWASM.
      *EIP-2045(click here https://eips.hereum.org/EIPS/eip-2045): Ethereum's volume is determined by 'gas rate' according to 'block gas upper limit'. One way to increase this volume is to raise the gas limit. However, increasing the gas limit increases the state's growth rate, which can have side effects such as economic assumption of gas cost or variables in the execution of practices. Another way to increase trading volume is to reduce gas costs. Reducing the gas cost of computational opcode increases the gas limit and the storage opcode, but does not cause any side effects. But since the gas price of computional code is close to 1, devs tried to split the gas cost measurement and run it in the EVM. The result was good. Measurements of gas, which are broken into smaller pieces, are called 'particles'.
    - I think it's good to concentrate on EIPs since EIP-1108, 1884 and 2028 related to gas fees have already been confirmed or suspended.
    - All EIPs related to gas cost require a lot of benchmarking to be accepted in HF, and a person in charge must do a lot of work related to benchmarking. Also, if it is not accepted in HF in October this year, it may be accepted in the next HF in April or July next year.
    - The proposed improvements to the forthcoming HF are EIP-663, 1380, 1985, 2045, 2046, and their benchmarking is urgent.
     1) EIP-663(https://eips.ethereum.org/EIPS/eip-663) : The SWAP and DUP commands, which are currently limited to the depth of 16 on the stack, are responded with SWAPn and DUPn, and access to all depths is allowed.
     2) EIP-1380(https://eips.ethereum.org/EIPS/eip-1380) : To reduce gas costs for the call-to-self, it reduces gas costs for call instructions when running a new instance of the currently loaded contract.
     3) EIP-1985(https://eips.ethereum.org/EIPS/eip-1985) : Applying the proper limit range for EVM parameters such as gas limit and block number. Applying explicit scope helps to implement compatible clients.
     4) EIP-2035(https://eips.ethereum.org/EIPS/eip-2035) : The pricing method to be re-settled when executing SLOAD and SSTORE for block verification. The price varies depend on the size of contract storage(i.e., the smaller contracts are, the cheaper they cost).


□ Conformance test

  ㅇ ReTestEth
    - To be accepted in the HF, Reference Implementation must be sufficient and accompanied by tests. One of the tools the client is using is 'ReTestEth'. Therefore, we agree to use ReTestEth
for testing all of the tentatively accepted EIPs.


□ Working group updates

  ㅇ About the tentatively accepted EIPs
    - As for EIP-1057 aka ProgPoW, audit has not been completed. For EIP-1962, accuracy is being reviewed. What we hope is to make tentatively accepted EIPs accepted ones for testnet HF and Istanbul HF asap, otherwise it will be accepted in next year's HF.


□ Personal Comments

  ㅇEthereum 2.0 foretasting
    - Ethereum devs' meetings were held a week later and there is little to comment personally on as discussions continue on EIPs to be accepted in IstanbulHF. Instead, I would like to explain Ethereum 2.0.
    - Vitalik recently tweeted that most studies on Ethereum 2.0 have been completed
and the specifications continue to be updated. The "Serenity" stage, which goes to Edereum 2.0, is the final step of Ethereum roadmap, with the most prominent features
such as the conversion of consensus protocols from PoW to PoS, conversion of virtual machines from EVM to EWASM, and the introduction of shading. Here, the specifications in Ethereum 2.0 have not yet been finalized, and so far the findings are so vast and difficult that I will not deal with everything, but I will briefly look at each step in Ethereum 2.0.

 <Step 0> Beacon Chain – Early 2020
   - Beacon chain alone would be a long story, but I'll focus on its concept and role. Beacon Chain is a chain that oversees itself and the Stake Proof protocol for all shard chains. The chain has many roles that manage validators('proposers' who create and propose blocks plus 'witnesses' who validate the proposals), recommand proposers for each shard, organize a randomly selected witness committee, apply agreement rules,
apply rewards and penalties for validators, and registrate state for inter-shard ransactions.
   - In particular, Beacon chain has a role associated with the 'Shard chain' that will appear in phase 1. When shard chain is deployed, each shard arbitrarily selects a validator that blocks transactions executed on the shard, and lets that validator vote by a witness committee of the shading version, which is also randomly selected. At this point, when the vote is done well, 'crosslink' is created, which means that it is ready to update transaction in beacon chain.
   - What is noteworthy in phase 0 is that the existing ETH should be converted to a different version of ETH. This is a new asset(ETH2) that will be used for beacon chain, which can be obtained by staking and acting as a validator in a beconchain or by purchasing an existing ETH(ETH1) and transfer it to beacon chain(However, the transmitted ETH1 cannot be transferred between shards, and it will be possible in phase 2).
   - For your information, at least 32ETH is required for staking and validation.

  <Stage 1>Shard Chain - 2020 
    - Shard chain is a chain that oversees shading, a scalable technology that divides data into numerous pieces and spaces to improve performance and management. At this stage, the transactions occurring in Ethereum chain are distributed in 1,024 chards, which allow much more transactions to be processed at the same time than before.
    - Reward is paid to both PoW miners and PoS validators, since the existing PoW chain will continue to operate even after Shard Chain is introduced.

  <Step 2>State execution – 2021 
    - Unlike phase 0 and 1 where new chains are introduced, phase 2 is a stage where many functions are integrated qualitatively. Shardchain is transformed from a simple data storage warehouse into a more structured chain, each of which manages virtual machines based on EWASM. It is also possible for the ETH to be transferred between the shards.
    - And the EWASM storage cost, the state rent system, is introduced, so that devs and users of smart contracts have to pay fees for storing code and data.

  <Later> Ethereum 3.0 - TBD 
    - Fully PoS-based Ethereum will be implemented. In addition, zk-STARKs, which are now more advanced than zk-SNARKs, will be introduced and combined.
    - 'Heterogenous Shards' is introduced, allowing for higher gas transactions without affecting other shards.
    - Other detailed plans are not known.

  ㅇNow that we know more about Ethereum2.0...
    - We've just been through Ethereum2.0 and even 3.0. It can be useful information for longterm holders, or boring for someone else. As an analyst and investor, it was good for me to wrap up Ethereum's roadmap. If I have nothing to write about devs meeting, I will introduce other aspects of Ethereum like today.


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 관련 이더리움개선제안(EIPs) 관련

  ㅇ 이스탄불HF 허용(+잠정보류) EIP에 대한 클라이언트 업데이트
    - 지난 회의를 통해 도래하는 HF는 올해 10월과 내년 초에 진행할수 있다는 가능성을 열었다. 또한, 이더리움 개발자들은 지난 회의를 통해 이스탄불HF에 허용 또는 잠정보류된 EIP에 대한 논의를 하였고, 그 EIP에 대한 각 클라이언트에 대한 업데이트를 하기로 하였다.
    - (Pantheon) 우리 Pantheon은 EIP-1057(ProgPoW 관련), EIP-1962(타원곡선 관련)을 구현하지 않았습니만, 우리의 개발 상황에서 허용 또는 잠정보류된 EIP 사양에 맞도록 구현하겠다.
    - (Nethermind) 우리는 EIP-1344(체인ID관련)와 EIP-2028(가스비 절감 관련)을 받아드렸고 EIP-1057(ProgPoW 관련)은 제외했으며, EIP-1962(타원곡선 관련)은 진행중에 있다. 나머지는 곧 시작하거나 중요하게 보고 있지 않다.
    - (Geth와 Parity) 이 두 클라이언트의 업데이트는 중요하므로, 다음 회의 전까지 실행하기를 바란다.

  ㅇ 이스탄불HF 잠정보류EIP 관련
    - 우리는 EIP-2045(EVM opcode상의 입자 가스비 관련)*가 잠정보류될만한 개선안이라고 보고 있다. 별도의 서브루틴을 도입하지 않아도 되고 점프작동방식을 변경하지 않아도 (확장성 해결을 위한) 속도향상을 기대할수 있다. EWASM팀의 관점으로 볼때도, EWASM의 잠재적 이점들 중 하나는 속도를 높이는 것이므로 입자 가스비 관련 EIP-2045는 EWASM에 있어서도 좋은 대안이 될것입니다. EVM과 클라이언트간 호환성을 최적화하면 EWASM을 활용하는 것보다 쉽고 빠를수도 있다.
      *EIP-2045(여기 클릭) : 이더리움의 거래량은 '블록가스상한(가스제한)'에 따른 '가스비'에 의해 결정됨. 이 거래량을 높이기 위한 하나의 방법은 '가스제한'을 높이는 것'임. 단, 가스제한을 높이면 스테이트 증가율도 올라가며, 이는 가스비의 경제 가정 문제나 컨트렉트 실행상 변수 문제 등의 부작용을 낳음. 거래량을 높이기 위한 또다른 방법은 '가스비를 줄이는 것'임. Computational opcode의 가스비를 줄이면, 가스제한을 높이고 storage opcode를 높이는 효과가 나면서도 부작용은 없음. 그런데 이 computational opcode의 가스비가 1에 가까우므로 가스비 측정치를 더 잘게 쪼개면서 EVM에서 실행하는 것을 시험해봤는데 그 결과가 괜찮았음. 이때 더 잘게 쪼개진 가스비 측정치를 '입자(Particles)'라고 함.
    - 이미 가스비와 관련된 EIP-1108, 1884, 2028이 확정 또는 잠정보류되었기 때문에 이것에 집중하는 것이 좋다고 생각한다.
     - 가스비 관련 EIP를 포함한 모든 잠정보류 EIP는 HF에 반영되기 위하여 많은 벤치마킹이 필하며, 담당자가 벤치마킹과 관련된 많은 작업을 해야한다. 또한 올해 10월 HF에 미반영되면 내년 4월이든 7월이든 차기 HF에 반영될수도 있다.
     - 앞으로 도래할 HF반영에 잠정보류된 개선안은 EIp-663, 1380, 1985, 2045, 2046이며 이들의 벤치마킹은 시급하다.
      1) EIP-663(https://eips.ethereum.org/EIPS/eip-663) : 현재 스택상 16의 깊이로 제한된 SWAP과 DUP명령어를, SWAPn과 DUPn으로 대응시키고 모든 깊이까지 접근을 허용함.
     2) EIP-1380(https://eips.ethereum.org/EIPS/eip-1380) : 자기호출에 대한 가스비 절감으로, 현재 로드된 컨트렌트의 새 인스턴스를 실행시 호출지시에 대한 가스비를 줄임.
     3) EIP-1985(https://eips.ethereum.org/EIPS/eip-1985) : 가스제한, 블록넘버 등 EVM 매개변수들에 대한 적정 한계범위를 적용. 명시적인 범위를 적용하면 호환가능한 클라이언트를 구현하는데 도움이 됨.
     4) EIP-2035(https://eips.ethereum.org/EIPS/eip-2035) : 블록검증을 위해 SLOAD와 SSTORE실행시 지불해야하는 가격 재책정방식으로, 컨트렉트 스토리지 크기에 따라 비용이 달라짐(가령, 컨트렉트가 작을수록 저렴해짐). 


□ 적합성 테스트

  ㅇ ReTestEth
    - HF에 반영되기 위해서는 참조구현(Reference implementation)이 충분하고 테스트가 동반되어야 합니다. 이를 위해 클라이언트가 사용되는 도구들 중 하나가 'ReTestEth'입니다. 따라서, 우리는 잠정보류된 모든 EIP의 테스트를 위하여 ReTestEth 사용에 동의합니다. 


□ 워킹 그룹 업데이트

  ㅇ 잠정보류 EIP에 대하여
    - ProgPoW로 유명한 EIP-1057의 경우, 감사가 완료되지 않았다. EIP-1962의 경우, 정확성을 검토중입니다. 이러한 잠정보류건이 어서 테스트넷HF와 이스탄불HF에 허용되는 것이 우리가 바라는 것이며, 그렇지 않으면 내년에 있을 HF에 반영될것이다. 


□ 개인 논평

  ㅇ 이더리움2.0 맛보기
    - 이더리움 개발자 회의가 1주일 간격으로 진행되었고, 계속해서 이스탄불HF에 반영될 이더리움개선안(EIP)에 대한 논의가 지속되고 있기때문에 딱히 논평할 거리가 없다. 그 대신에 이더리움2.0에 대한 설명을 하고자 한다. 
    - 최근 비탈릭은 트위터를 통해 이더리움2.0에 대한 대부분의 연구가 완성되었고 스펙은 계속 업데이트 된다고 언급하였다. 이더리움2.0으로 통하는 '세레너티(Serenity)' 단계는 이더리움 마스터플랜의 최종 단계로, 가장 두드러진 특징으로는 PoW에서 PoS로의 합의프로토콜 전환, EVM에서 EWASM으로의 가상머신 전환, 샤딩 도입 등이 있다. 여기선, 이더리움2.0에서의 스펙이 아직 최종적으로 확정되지도 않았고, 현재까지 밝혀진 내용도 워낙 방대하고 난해하기 때문에 모든걸 다루지 않고 이더리움2.0에서의 각 단계별 내용에 대해 간단히 알아보겠다.
< 이더리움2.0의 여러 체인(https://www.mycryptopedia.com) >


  <0단계> 비콘체인(Beacon Chain) - 2020년 초
   - 비콘체인만 다뤄도 아주 긴 글이 되겠지만, 그 개념과 역할 위주로 정리해보겠다. 비콘체인은 비콘체인 자체체인과 모든 샤드체인에 대한 스테이킹 증명 프로토콜을 총괄하는 체인이다. 이 체인은 검증인(블록을 생성하고 제안하는 '제안자' + 그 제안을 검증하는 '증인')과 그들의 스테이킹 관리, 각 샤드에 제안자를 추천, 검증인을 임의선정한 증인위원회 구성, 합의규칙 적용, 검증인에 대한 보상과 페널티 적용, 샤드간 거래를 위한 스테이트 등록 등의 역할을 수행한다.
     - 특히, 다음단계인 1단계에서 등장할 '샤드체인'과 관련된 역할이 있다. 샤드체인이 배치되면, 각 샤드는 샤드에서 실행된 트랜잭션을 블록화하는 검증인을 임의선정하며, 그 검증인으로 하여금 역시 임의선정된 샤딩버전의 증인위원회에 의해 투표하게한다. 이때 투표가 잘 이행되면 크로스링크가 생성되는데, 이는 곧 비콘체인에 트랜잭션 업데이트를 할 준비가 되었다는 뜻이다.
     - 0단계에서 주목할만한 점은 기존 ETH를 다른 버전의 ETH로 전환해야한다는 점이다. 이는 비콘체인에 사용될 새로운 자산(ETH2)으로, 비콘체인에서 스테이킹을 하고 검증인 역할을 하거나 기존의 ETH(ETH1)을 구매하여 비콘체인으로 전송하여 얻을수 있다. (단, 전송한 ETH1은 샤드간 전송이 불가하며 2단계가 완료되어야 샤드간 전송이 가능하다).
      - 참고로 유효성 검증과 그에 따른 보상을 받기 위한 스테이킹은 최소 32이더가 필요하다. 

  <1단계> 샤드체인(Shard Chain) - 2020년 
    - 샤드체인은, 성능과 관리를 개선하기 위하여 데이터를 수많은 조각과 공간으로 나눠 보관하는 확장성 기술인 샤딩을 총괄하는 체인이다. 이 단계에서 이더리움 체인에서 발생하는 트랜잭션이 1,024개의 샤드로 분산되며, 이때 기존보다 동일한 시간에 훨씬 더 많은 트랜잭션을 처리할수 있다.
    - 샤드체인이 도입되어도 기존의 PoW체인은 계속 작동하므로, 보상이 PoW채굴자와 PoS검증인 모두에게 지급된다. 

  <2단계> 스테이트 실행(State execution) - 2021년 
   - 새로운 체인이 도입되는 0단계와 1단계와는 달리, 2단계는 질적으로 여러 기능이 통합되는 단계다. 샤드체인은 단순 데이터 보관창고에서 더욱 구조화된 체인으로 탈바꿈되며, 각 샤드는 EWASM을 기반으로 가상머신을 관리한다. 또한 비로소 샤드간 ETH가 전송이 가능해진다.
    - 그리고 EWASM 스토리지 비용인 스테이트 임대수수료(State rent)제도가 도입되어, 스마트 컨트렉 개발자와 사용자는 코드와 데이터를 저장하기 위한 수수료를 지불해야 합니다.
 
  <추가샤딩1> 라이트 클라이언트 스테이트 프로토콜(Lightc-client State Protocol) - 2022년
    - 사용자들은 스토리지 임대수수료를 직접 지불하거나 2차시장(필자주 : 회사 경영권이 주식이라는 형태로 증권시장에 상장되어 거래되듯이, 스토리지 사용권도 별도로 거래될수도 있다는 의미같음)을 통해 지불될 예정이다.
     - 기타 세부 계획은 알려지지 않음.

  <추가샤딩2> 샤드간 트랜잭션(Cross-shard transactions) - 미정
    - 내부적으로 샤드와 샤드와 관련된 기술이 내실화된다.
    - 기타 세부 계획은 알려지지 않음.

  <추가샤딩3> 샤드와 메인체인간 긴밀한 보안 공조(Tight coupling with Main-chain Security) - 미정 
    - 포크가 필요없는 샤딩기술이 도입된다.
    - 기타 세부 계획은 알려지지 않음.

  <추가샤딩4> 샤드의 샤드(Super-quadratic or exponential Sharding) - 미정
    - 샤드안에 샤드가 있고 또 그안에 샤드가 있는 '재귀적으로 존재하는 샤드'가 도입된다.
    - 기타 세부 계획은 알려지지 않음.

  <이후 단계> 이더리움3.0 - 미정 
    - 진정한 Full PoS기반의 이더리움이 구현될 예정이다. 또한 현재 영지식증명기술인 zk-SNARKs보다 더 진보된 zk-STARKs가 도입 및 결합될 예정이다.
    - '이질적인 샤드(Heterogeneous shards)'라는 것이 도입되어, 다른 샤드에 영향을 끼치지 않으면서 더 높은 가스 트랜잭션을 허용할수 있다.
    - 기타 세부 계획은 알려지지 않음.

  ㅇ 이더리움2.0 단계를 알고보니,,,
     - 이더리움2.0을 넘어선 이더리움3.0까지 작성하고보니, 이글을 읽고있는 누군가에겐 장투를 위한 유용한 정보가 될수도 있고, 다른 누군가에겐 장투하기도 전에 질려버릴수도 있다. 다만, 필자는 투자자이면서 분석가이기에 스스로 이더리움의 로드맵을 정리할 겸 소개할 겸 해서 정리하고 공유해봤다. 앞으로도 이더리움 개발자 회의와 직결되는 논평을 작성하기 애매할 경우, 이더리움2.0과 같은 이더리움의 다른 측면도 소개할예정이므로 기대하길 바란다.  


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


<Reference>
 1) https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-phases/
 2) https://github.com/ethereum/wiki/wiki/Sharding-roadmap#phase-3-light-client-state-protocol
 3) https://www.mycryptopedia.com/ethereum-beacon-chain-explained/
 4) https://medium.com/ethhub/the-basics-of-ethereum-2-0-economics-3bd2ffc7fd0e
 5) https://notes.ethereum.org/s/rkhCgQteN#Why-32-ETH-validator-sizes

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

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