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

# Ravencoin Devs Meeting(30 Aug 2019) 

(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

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