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

# Ravencoin Devs Meeting(20 Dec 2019) 

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

□ Analysis of the meeting by subject 

 ㅇProposal of new algorithm
   - Jeroz shared a link* to the next algorithm proposal for ASIC resistance written by Playhard and Whitefire.
    * Playhard's : https://github.com/Alterhash-Sandbox/RVN-v3/blob/master/whitepaper/Alterhash%20-%20XDag16R%20v1.0.pdf
      Whitefire's : https://drive.google.com/file/d/1w-Sfk9bjRBfAGyBoM277kz_0ifD7kVEZ/view

   - Playhard said his proposal requires proper understanding first and Tron said Playhard's proposal addressed the SPV* wallet issue, adding that we can't require a phone to have 2GB dedicated to validating blocks.
    * SPV(Simplified Payment Verification: A node that stores block and transaction verification itself(Full nodes) by storing all blocks from genesis block to the current block, which is 1 to 3% as compared to a full node without its transactions, but requires the help from full nodes when verifying transactions

 ㅇBug bounty
   - As for bug bounty closed on Dec 19, Tron said we haven't gotten much feedback, good or bad, and no consensus bugs were reported that he's aware of.
   - Push argued that we should extend the bug bounty period because there may be problems we overlooked and there are not enough people looking at yet. Tron added that we could extend the bounty if we think that more time is warranted and are trying to catch bugs before we launch.

 ㅇThe upcoming fork schedule
   - Tron said we will likely set the date to the Jan 3rd, but release binaries on the 6th.
   - Jeroz said he couldn't understand the difference between January 3 and January 6. Then, Tron further explained that the fork will occur after exchanges and clients follows it after the announcement of the binary release on January 6.
   - Tron also set the supporting rate for the miners needed to push for the fork at 1612 blocks(=80%) out of the 2016 blocks, and other devs agreed.

 ㅇLegal fund
   - liqdmetal said he needed a bug reward or legal funding for security audits (if problems with coding causes damage to tokenized assets). Tron explained that legal funds are also needed when lawyers argue ravencoin will not be considered as a security for listing in exchanges.
   * Legal fund: fund that attoneys or lawyers receive for legal action and legal advice. Some legal professionals received some amount of Raven or consulted for free when they claimed that Ravencoin was not a security to be listed in Bittrex.

□ Personal comments

 ㅇRaven Coin Development Roadmap
   - There are a total of seven steps in the development of Ravencoin, which are as follows.
    1) Stage 1: Releasing Ravencoin mainnet - Completed on January 3, 2018
    2) Step 2: Implementing "Assts" -Completed on November 5, 2018
    3) Step 3: Implementing "Dividends/Rewards"
    4) Step 4: Implementing "Subassets & Unique Assets" -Completed on 5 November 2018
    5) Step 5: Implementing "Messaging, OIP and Restricted Assets functions"
    6) Step 6: Implementing "Voting"
    7) Step 7: Compatible mode

   - Except for steps 1, 2, and 4 completed so far and the maintenance steps 7, only steps 3, 5 and 6 will remain. And steps 3 and 5 will be implemented on the main net through the upcoming fork. Considering that the remaining step 6 will be implemented in the first half of 2020, it seems that development of Ravencoin will be almost done in near future. Therefore, the next fork is very important and I will explain once again the fork process described in the November 22 devs meeting.

 ㅇFork process
   - A project that follows Bitcoin Implementation Proposals(BIP), such as Bitcoin and Ravencoin, shall follow BIP9 when soft/hard fork is performed. BIP9 is how it is defined when upgrading to a new version and how much it is supported by the miners, which the network participants can interpret as a vote on a new upgrade. Note that RIP2 has the same function as BIP9 in Ravencoin.
   - Forks according to BIP9/RIP2 have a total of four stages, which are as follows.

   1) Define stage: Devs define the version bits to be planted on the blockheader for signalling and define how many blocks to be supported.
   => The versionbit to be planted on the blockheader for the next fork in RavenCoin is set at 7, and it has yet to be determined how many blocks to which it will be supported.

   2) Start stage: When various criteria are defined in Define stage, a vote is started to check whether support is supported. For your information, voting will be conducted from N Block to N+2016 blocks, taking into account the adjustment of mining difficulty for each block of 2016. Note that if you receive more than 65% of support under RIP2, testnet is activated, and if you receive more than 80%, mainnet is activated.
    => The '1612 block' referred to by Tron at this meeting represents the minimum number of support blocks for fork activation among the 2016 blocks 
for which mining difficulty is adjusted, 80%. In other words, if the binary is announced later and exchanges and clients are ready to upgrade to the latest version, the voting will begin on a specific N block and the primary fork will be completed when the N+2016 block is reached.

   3) Lock-in Phase: With 80 percent (or 65 percent) of support, new upgrade will be locked during another 2016 block for mainnet (or test net) release.
    => Once sufficient support has been obtained from the miners who are participants in Ravencoin network, the final verification period is set through the final cycle, 2016block.

   4) Activate Step: If there is nothing special in Lock-in, the network upgrade is completed as mainnet is activated.
    => If no bug or attack is found during the final verification period, the fork is completed as soon as the last 2016 block is passed.

 ㅇThe expected timing and significance of the next fork
   - Given all this, I expect the next fork to be in February 2020. This is because after the binary was announced on January 6, exchanges and clients prepare for the latest version for three to six weeks, and four-step fork process with a ready-to-up period to upgrade for about three days. The fork schedule has been somewhat delayed, but I hope the fork will be implemented without any further problems.
   - The fork process may not yet be clearly understood, even though I explained twice. Even if you couldn't understand, the more important thing is to support it as a member of the community until the fork. It is very surprising and difficult to develop the network and community in a way that network participants vote directly, compared to the practice of representative democracy in most countries through congress in our real world. We are doing this amazing and difficult task now. That is why we should take seriously the next fork, whose main functions will be implemented on its mainnet soon.

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.

(한국어 버전)

□ 소재별 회의 내용

 ㅇ차기 알고리듬 제안
   - Jeroz는 Playhard와 Whitefire가 작성한 ASIC저항을 위한 차기 알고리듬 제안서의 링크*를 공유했다.
    * Playhard's : https://github.com/Alterhash-Sandbox/RVN-v3/blob/master/whitepaper/Alterhash%20-%20XDag16R%20v1.0.pdf
      Whitefire's : https://drive.google.com/file/d/1w-Sfk9bjRBfAGyBoM277kz_0ifD7kVEZ/view
    - Playhard는 그의 제안서에 대하여 우선적으로 올바른 이해가 필요하다고 말했고 Tron은 Playhard의 제안서는 SPV*지갑의 중요성을 일깨웠다면서 모바일로는 블록검증을 위해 2GB는 무리라고 말했다.
    * SPV(Simplified Payment Verification) : 제네시스 블록부터 현재 블록까지 모든 블록을 저장하여 블록 및 트랜잭션의 검증을 자체 수행하는 풀노드(Full nodes)와는 달리 트랜잭션을 제외한 블록헤더만을 저장한 노드로 풀노드 대비 1~3%의 크기를 가져 휴대성이 높지만 트랜잭션 검증때 풀노드의 도움이 필요함

 ㅇ버그 바운티
   - 12월 19일에 마감된 버그바운티에 대해서 Tron은 좋은쪽으로든 나쁜쪽으로든 많은 피드백을 받지 못했고 합의에 대한 버그가 보고되지 않았다고 말했다.
   - push는 우리는 우리가 간과하고 있는 문제가 있을수 있고 아직 충분히 많은 사람들이 살펴보지 않았기 때문에 버그 바운티 기간을 연장해야한다고 주장했다. 이에 Tron은 우리가 더 많은 시간이 필요하다고 생각하면 연장가능하다고 언급하면서 차기 포크 이전에 우리는 버그를 해결해야한다고 첨언했다.

 ㅇ차기 포크 일정
   - Tron은 아직까지는 차기 포크일을 1월 3일로 유지하지만 바이너리(최신버전 프로그램 실행파일)은 1월 6일에 출시할거라고 말했다.
   - 이에 Jeroz는 1월 3일과 1월 6일에 대한 차이점을 이해할수 없다고 말했고
Tron은 잠정적으로 1월 3일이 차기 포크일이나 1월 6일 바이너리 발표 이후 거래소가 그것을 따르고 난 이후에 포크가 일어날거라고 추가설명했다.
   - 아울러 Tron은 포크를 추진하기 위해 필요한 채굴자들의 지지율을 2016블록 중 1612블록(=80%)로 정하였고 다른 개발자들도 동의했다.

 ㅇ법률 자금
   - liqdmetal은 (코드의 문제가 생겨 토큰화된 자산에 피해가 있을 경우) 버그 현상금이나 보안 감사를 위한 법률자금*이 필요하다고 말했고
Tron은 법조인이 레이븐코인이 거래소상장시 증권으로 간주되지 않기 위한 변론을 펼칠때도 법률 자금이 필요하다고 설명했다.
    * 법률자금(Legal fund) : 법정소송, 법률자문 등 법정 비용을 지불하기 위한 자금으로 레이븐이 비트렉트 상장을 위해 증권이 아님을 주장할때 일부 법조인들이 일정 수량의 레이븐을 받거나 무료로 법률자문을 한 바 있음

□ 개인 논평

 ㅇ 레이븐코인 개발 로드맵
   - 레이븐코인 개발에는 총 7개 단계가 있으며 그것은 다음과 같다.
    1) 1단계 : 레이븐코인 메인넷 출시 -2018년 1월 3일 완료
    2) 2단계 : 자산(Assts) 기능 구현 -2018년 11월 5일 완료
    3) 3단계 : 배당/보상(Dividends/Rewards) 기능 구현
    4) 4단계 : 보조자산 & 고유자산(Subassets & Unique assets) 기능 구현 -2018년 11월 5일 완료
    5) 5단계 : 메시징(Messaging), OIP, 제한자산(Restricted Assets) 기능 구현
    6) 6단계 : 투표(Voting) 기능 구현
    7) 7단계 : 호환 모드
   - 현재까지 완료된 1, 2, 4단계와 사실상 유지관리 단계인 7단계를 제외하면 3, 5, 6단계가 남아있으며 3단계와 5단계는 다가오는 포크를 통해 메인넷에 구현될 예정이다. 나머지 6단계도 2020년 상반기에 구현될 것을 감안하면 개발측면에서는 레이븐코인이 9부능선을 넘었다고 봐도 무방하다. 따라서 차기 포크는 매우 중요하며 지난 11월 22일 회의 논평에 설명한 포크 과정에 대해서 다시 한번 설명하겠다.

 ㅇ차기 포크 과정
   - 비트코인, 레이븐코인 등 BIP(Bitcoin Imporvement Proposals, 비트코인 개선안)를 따르는 프로젝트는 소프트/하드포크를 할 경우 BIP9를 따른다. BIP9란 새로운 버전으로 업그레이드시 그것을 어떻게 정의하고 채굴자들로부터 그것을 얼마나 지지받는지 확인받는 것으로 네트워크 참여자가 새로운 업그레이드에 대한 투표로 해석하면 된다. 참고로 레이븐코인에도 BIP9와 같은 기능을 지닌 RIP2가 존재한다.
   - BIP9/RIP2에 따른 포크는 총 4단계가 있으며 그것은 다음과 같다.

  1) Define단계 : 개발자들은 지지여부(Signaling)를 위하여 블록헤더에 심을 버전비트를 정하고, 몇 블록부터 몇 블록까지 지지여부를 확인할것인지 정의한다.
   => 레이븐코인의 차기 포크를 위하여 블록헤더에 심을 버전비트는 7로 설정된 상태이며 아직 몇 블록부터 몇 블록까지 지지여부를 확인할것인지 정해지지 않았다.

  2) Start단계 : Define단계에서 여러 기준이 정의되면 지지여부를 확인하는 투표가 시작된다. 참고로 2016블록마다 채굴난이도가 조정되는 것을 감안하여 N블록에서 N+2016블록까지 투표가 진행된다. 참고로 RIP2에 따라 65% 이상의 지지를 받으면 테스트넷이 활성화되고, 80% 이상의 지지를 받으면 메인넷이 활성화된다.
   => 이번 회의에서 Tron이 언급한 1612블록은 채굴난이도가 조정되는 2016블록 중에서 포크추진을 위한 최소 지지블록수를 의미하는 것으로 80%이다. 즉, 추후 바이너리가 발표되고 거래소와 클라이언트가 최신버전 업그레이드 준비가 될경우 특정N블록에서 투표가 시작되고 N+2016블록에 이르면 1차적인 포크가 완료된다.

  3) Lock-in단계 : 80%(또는 65%)의 지지를 받으면 메인넷(또는 테스트넷) 출시를 위해 또다른 2016블록기간동안 새로운 업그레이드를 걸어잠근다.
   => 레이븐코인의 네트워크 참여자인 채굴자들로부터 충분한 지지를 받고나면 마지막 사이클인 2016블록을 거치면서 최종 검증 기간을 둔다.

  4) Activate단계 : Lock-in단계에서 특이사항이 없으면 비로소 메인넷이 활성화되면서 네트워크 업그레이드가 완료된다.
   => 최종 검증 기간에 어떠한 버그나 공격이 발견되지 않으면 마지막 2016블록이 지나자마자 포크가 완료된다.

 ㅇ차기 포크의 예상시점과 의의
   - 이 모든 것을 감안했을때 필자는 차기 포크 시점이 2020년 2월로 예상하고 있다. 1월 6일 바이너리가 발표되고 3주에서 6주동안 거래소와 클라이언트가 최신버전을 업그레이드할 준비기간을 갖고 3일간의 4단계 포크과정이 필요하기 때문이다. 포크 일정이 다소 지연되었지만 아무 문제없이 포크가 이행되길 바란다.
   - 2주전 논평과 이번 논평에 걸쳐 설명했음에도 불구하고 아직 포크과정이 확실히 이해되지 않을수도 있다. 설령 이해되지 않는다해도 중요한것은 포크시점까지 커뮤니티의 일원으로서 그것에 대해 관심을 갖고 지지하는 것이다. 현실세계에서는 대부분의 국가에서 의회를 통해 대의민주주의를 시행하고 있는 것과 비교할때 네트워크 참여자들이 직접 투표하는 방식으로 해당 네트워크와 커뮤니티를 발전시키는 것은 매우 놀라우면서 어려운 일이다. 그 놀랍고 어려운 작업을 우리는 지금 하고 있다. 그 점이 바로 우리가 주요 기능이 메인넷에 구현될 차기 포크를 진지하게 대해야 하는 이유이자 책무이다.

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

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

#77 Devs Meeting Review(13 Dec 2019)

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

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

□ Istanbul HF Updates

  ㅇ Istanbul HF completed
    - Hudson mentioned the Istanbul HF successfully completed several days ago, and according to Ethernode, 97% of the nodes are updated. 

□ Muir Glacier Updates

  ㅇ Concern about the difficult bomb
    - Hudson said that Muir glaacier is in last call and we will change that to final, adding the review ended yesterday and no one raised any concerns. 
Tim said some in the Magician pointed out that 4 million blocks daly was too far, and Peter also believed that someone think we all of a sudden delay Ethereum 2.0 by delaying difficult bomb. 

    - Hudson dismissed such comments as misunderstanding of Ethereum 2.0 and said we should mark Muir Glacier EIP final. 
Peter also said it was too late to to start the debate on weather 4 mil or 3.9 mil or however much would be more appropriate, suggesting that we go ahead and it's completely fine to adjust in the next work, if someone is really opposed to it for some reason. 

    - Hudson suggested that since Muir glacier HF will happen on December 31 or January 1 next year, there should be even a light meeting in two weeks.
Peter said let's wait two more days to accurate the forecast of when Muir glacier HF goese, and Hudson said to post about the HF next Thursday. 

□ Berlin HF tentatively accepted EIPs review

  ㅇ EIP-1559*
   * EIP-1559: Away from current inefficient and unnecessary gas costs, this will adjust basic network charges according to network demand, increase cost efficiency, and increase user convenience in gas charge.

    - Rick explained this EIP proposed by Vitalik as follows; It increases stability in gas pricing, has some other useful side effects in terms of removing zero fee transaction, and sets additional gas charges under consensus over basic fee. 
It also simplifies the user experience to facilitate the determination of total gas costs in advance. 

    - When Martin asked about the subject of the base fee, Rick answered that the base fee targets the half-full block. Peter then questioned what would happen if we were to remove the limit on mainnet, saying that there was a gaslimit fixed at 10 million per block on Ethereum mainnet and that it would be likely that the miners keep growing the block under the basic fare system. Rick answered that the gas cost can be adjusted without block gaslimit, and Peter said that it should be important to touch on what happens on a network where we don't have this limit even if we keep the gaslimit for now.

  ㅇ EIP-1962* and EIP-1057**
   * 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.
   ** 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.

    - Devs had technical discussions on the two EIPs and EIP-1962 continued to be discussed in EthMagician and EIP-1057 concluded that HF(Hardfork) was needed in the future.

Disclaimer: Since this post was written for the purpose of providing information for investment, please be careful in your investment decision. You cannot copy, distribute, or edit the contents without my permission because it was made based on my own judgment based on the reference data.

(한국어 버전)

□ 이스탄불HF 업데이트

  ㅇ 이스탄불HF 완료
    - Hudson은 12월 8일 성공적으로 완료된 이스탄불HF에 대해 언급했고, Ethernode에 따르면 97%노드가 업데이트를 완료했다고 전했다. 

□ 뮤어 빙하 업데이트 

  ㅇ 난이도 폭탄 연기에 대한 우려
    - Hudson은 우리가 뮤어 빙하에 대한 검토를 마쳤고 Ethereum Magician에서 의문을 제기하지 않았으므로, 뮤어빙하HF의 EIP를 '마지막승인(Last call)'단계에서 '승인확정(Final)'단계로 바꿀거라고 말했다. 이에 Tim은 Magician에서 몇몇이 4백만 블록 연기가 너무 과한 조치라고 지적했고, Peter 역시 누군가가 뮤어 빙하를 통한 난이도 폭탄 연기를 이더리움2.0연기로 이어질거라고 간주했다고 전했다. 

    - Hudson은 그런 의견들에 대하여, 이더리움2.0에 대한 오해라고 일축했고 뮤어 빙하 EIP에 대해 승인확정을 하자고 말했다. Peter 역시 난이도 폭탄을 연기시킬 블록에 대한 것이나 4백만 블록 연기가 맞는지에 대한 것이나 그것을 논의하기에는 매우 늦었다고 말하면서, 일단 뮤어빙하HF를 진행하되 누군가 근거있는 반박을 하면 향후 조치하면 될것이라고 제안했다. 

    - Hudson은 뮤어빙하HF가 12월 31일이나 내년 1월 1일에 일어날것이므로, 2주 후에 가벼운 회의라도 해야한다고 제안했다. Peter는 뮤어빙하HF가 일어나는 시점의 예측도를 높이기 위해 2일 더 기다려보자고 말했고, Hudson은 뮤어빙하에 대한 글을 다음주 목요일에 게시하자고 말했다.    

□ 베를린HF 잠정승인EIP 리뷰 

  ㅇ EIP-1559*
   * EIP-1559: 현재의 비효율적이고 불필요한 가스비가 드는 방식을 벗어나, 네트워크 수요에 따라 기본 네트워크 요금을 조정하고 비용 효율성을 높이며 가스비지불에 있어 사용자 편의성을 높임.

    - Rick은 비탈릭이 제안한 이 EIP에 대해 다음과 같이 설명했다; 가스비 책정에 안정성을 높이고, 수수료없는 트랜잭션을 없애되 기본요금을 두고 합의하에 추가 가스비를 정한다. 또한 사용자경험을 단순화하여 사전에 총 사용가스비 책정을 용이하게 한다.   

    - Martin이 기본요금의 부과대상에 대해 묻자, Rick은 블록의 절반에 부과된다고 답변했다. 그러자 Peter는 이더리움 메인넷에서는 1000만으로 고정된 블록당 가스상한제한이 있고 또한 기본요금제에서는 블록을 계속 키우는게 채굴자에게 이익이 될거라면서, 블록가스제한이 없어지게된다면 무슨일이 벌어지는지 의문을 제기했다. 그 의문에 Rick은 블록가스제한없이 가스비를 조정하면 된다고 답했고, Peter는 블록가스제한을 유지한다해도 그 블록가스제한이 없을때 네트워크에 어떤일이 발생할지 분석하는게 중요하다고 말했다. 

  ㅇ EIP-1962* 및 EIP-1057
   * EIP-1962: 타원 산술 및 런타임 정의와 결합에 대한 개선안으로, EIP-1829에 대한 확장안이며 EIP-1109에서의 STATICCAL opcode보다 작업비용이 더 저렴.
   ** EIP-1057: ProgPoW로 불리며, ASIC의 향상된 효율성을 반감시키위하여, 상용GPU자원을 최대한 활용되도록 수정.

    - 개발자들은 두 EIP에 대한 기술적 논의를 했고 EIP-1962는 EthMagician에서 계속 논의하고 EIp-1057은 향후 HF(하드포크)가 필요하다고 결론지었다. 

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

[Ravencoin] Ravencoin Devs Meeting(06 Dec 2019) // 12월 6일 레이븐 개발자 회의 분석 및 논평 v1.0

# Ravencoin Devs Meeting(06 Dec 2019) 

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

□ Analysis of the meeting by subject 

 ㅇBounty program
  - Tron said devs have talked about extending the deadline because Bounty program currently ends on Dec 19th because they haven't received much feedback yet.

 ㅇEmail List
  - Tron said he just sent out an update and there has beent about 380 sign-ups. He also introduced the imbedded code of the email list for those who run the site.
   1) General update : <iframe src="https://cdn.forms-content sg-form.com/8ec7a872-d599-11e9-ada2-7a44cc589a29"/>
   2) Development update: <iframe src="https://cdn.forms-content sg-form.com/96861d25-0b10-11ea-b9d3-a63f003f1823"/>

  - Tron also mentioned a website that contains relevant information for those who have not yet applied for an email list.
   * https://rvn.postach.io/

 ㅇDevelopment status
  - Blondfrogs said they are going to implent features such as restricted assets, essaging and tags on mainnet by Jan 3rd, 2020 at the latest, but will not rush ahead before Christmas and the year-end holiday season. He also said devs are will working on the wallet GUI update and starting to release smaller updates that will include small GUI additions, hoping to get feedback as the new GUI  is built.
  - WuKong said there are a lot of activities from Asia, especially S. Korea because we're building up Bigger companies by good leaders by good working. And he asked y what features will be on the mainnet for the upcoiming update. Tron, in response, said the network upgrade will include six features, with four features which arerestricted assets, messaging, tags and memos needing forks, while the rest of dividends, rewards don't need forks.

□ Personal Comments

 ㅇNetwork upgrade is coming soon!
  - There is a high possibility that the next network upgrade, originally scheduled for mid-December, will be delayed to January next year. Because currently, restricted assets, messaging, tags, memos, dividends, and rewards are on testnet and bounty program might be extended. Plus, Christmas and year-end holidays are ahead. This network upgrade is very important because it embodies the major features of Raven platform on mainnet and we hope that they will be implemented well without any problems even if there is a delay.
  - In the past, I had many complaints about delays in the implementation schedule of projects that I was also interested in. So I began to go through their devs meetings to find out the reason of delays, and I thought it was natural to delay it in the end. Because many people are cooperating little by little because of the nature of open source, it is difficult to even set a deadline, let alone meet the deadline technically and timing. Of course, 'delay for delay' should be avoided, but 'delay for better tests' should be accepted naturally by the community.

 ㅇRaven flies away in 2020!
  - Bitcoin, which was created based on blockchain at a time when the U.S. took the lead in printing money after the 2008 global financial crisis, came into the world in early January 2009 when it was in the midst of a global Great Recession. Nine years later, Raven was born by diverging from Bitcoin in early January 2018 during the Great Recession of coinmarket, which came after the all-time coin boom in 2017. Just as Bitcoin was launched during the global Great Recession to replace existing currencies and systems, Raven came with great potential to expand the base of blockchain and cryptocurrency, as did Bitcoin and Ethereum before.
  - Those great coin projects have been developed as assets of tremendous value, with enthusiastic developers and their users and supporters who have recognized their values, even if the beginning was feeble. Raven will implement key features on mainnet later this year or early next year, and will be judged on how much potential it will emit afterwards. As it has been, it may face many obstacles as it grows bigger, but it is hoped that devs, users and communities will gather to maximize its potential in the future.

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.

(한국어 버전)

□ 소재별 회의 내용

 ㅇ바운티 프로그램
  - Tron은 바운티 프로그램이 현재로써는 12월 19일에 마감하지만 아직 많은 피드백을 받지 않았기 때문에 마감시한을 연장하는 것에 대해 논의했다고 말했다.

 ㅇ이메일 리스트
  - Tron은 레이븐 이메일 리스트를 전송하고 있으며 약 380명이 구독신청했다고 말했다.
I just sent out an update. There's about 380 sign-ups
    또한 그는 사이트를 운영하는 이들을 위하여 이메일 리스트 삽입코드를 안내했다.
   1) 일반 업데이트 : <iframe src="https://cdn.forms-content.sg-form.com/8ec7a872-d599-11e9-ada2-7a44cc589a29"/>
   2) 개발 업데이트 : <iframe src="https://cdn.forms-content.sg-form.com/96861d25-0b10-11ea-b9d3-a63f003f1823"/>
  - 아울러 Tron은 이메일 리스트를 미처 신청하지 못한 이들을 위해 관련 정보를 한데 모은 사이트*를 소개했다.
   * https://rvn.postach.io/

 ㅇ개발 현황
  - Blondfrogs는 현재 테스트넷에서 검토중인 제한자산, 메시징, 태그 등의 기능은 늦어도 2020년 1월 3일까지 메인넷에 구현하도록 노력하겠지만 크리스마스와 연말 휴가 시즌 이전에 급박하게 추진하지 않을것이라고 말했다. 또한 그는 현재 작업중인 지갑GUI업데이트에 대해서도 사소한 업데이트를 먼저 시행할것이며 많은 피드백을 받기를 바란다고 말했다.
  - WuKong은 아시아, 특히 한국에서 레이븐 활성화를 위한 많은 활동들이 있다고 말하면서 훌륭한 리더들덕분에 커뮤니티가 계속 커지고 있다고 말했다. 또한 그는 정확히 다가오는 네트워크 업그레이드에 어떤 기능들이 포함되는지 물었다. 이에 Tron은 이번 네트워크 업그레이드에 6개의 기능이 포함될것이며 제한자산, 메시징, 태그, 메모 등 4개 기능은 포크가 필요하고 나머지 배당, 보상 기능은 포크가 필요하지 않다고 말했다.

□ 개인 논평

 ㅇ 네트워크 업그레이가 다가온다
  - 당초 12월 중순으로 예정된 차기 네트워크 업그레이드가 내년 1월로 지연될 가능성이 높아졌다. 왜냐면 현재 제한자산, 메시징, 태그, 메모, 배당, 보상 등의 기능은 문제없이 검토중이지만 12월 19일에 마감될 바운티 프로그램이 연장될수도 있고 크리스마스와 연말 휴가를 앞두고 있기 때문이다. 이번 네트워크 업그레이드는 레이븐 플랫폼의 주요 기능들을 메인넷에 구현하는 것이기 때문에 매우 중요하며 지연을 하더라도 문제없이 잘 이행되기를 바란다.
  - 한때는 필자도 관심있는 프로젝트의 추진 일정이 매번 지연되는 것에 대해 불만이 많았다. 그래서 그 사유를 알아보기위해 개발자 회의나 개발 내용을 나름대로 찾아봤는데 결국엔 지연되는게 어쩌면 당연하다는 생각이 들었다. 왜냐면 오픈소스의 특성상 여러 사람들이 조금씩 협업을 하고 있기때문에 시기적으로나 기술적으로 마감기한을 지키기는 커녕 그 마감기한을 정하는 것조차 어렵기때문이다. 물론 개발자들은 '지연을 위한 지연'은 지양해야겠지만 '더 나은 검증을 위한 지연'은 커뮤니티가 자연스럽게 받아들여야한다고 생각한다.

 ㅇ2020년 레이븐의 비상
  - 2008년 글로벌 금융위기 이후 미국을 필두로 하여 화폐를 마구 찍어내던 시기에 블록체인을 기반으로 탄생한 비트코인은 글로벌 대침체기에 한창이던 2009년 1월 초에 세상에 나왔다. 그리고 그로부터 9년뒤 레이븐은 2017년 역대급 코인붐이후 찾아온 코인시장 대침체기가 한창이던 2018년 1월 초에 비트코인으로부터 분기되어 탄생하였다. 비트코인이 글로벌 대침체기때 기존 화폐와 시스템을 대안하기 위해 출시된것처럼 레이븐은 코인시장 대침체기때 비트코인, 이더리움이 그랬듯이 블록체인과 암호화폐의 저변을 확대할수 있는 엄청난 잠재력을 안고 출시되었다.
  - 그 위대한 프로젝트들은 비록 시작은 미약했을지라도 열정적인 개발자들과 그것들의 가치를 알아본 채굴자, 사용자, 지지자들이 모여 엄청난 가치를 지닌 자산으로 거듭났다. 레이븐은 올해말이나 내년초에 주요 기능을 메인넷에 구현할것이고 이후 그 잠재력이 얼마나 발산할지 심판을 받을 것이다. 여태 그랬듯이 더 크게 성장하면서 많은 장애물을 마주할수도 있지만 앞으로도 개발자, 사용자, 커뮤니티가 뜻을 모아 그 잠재력이 극대화되길 바란다.

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

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

#76 Devs Meeting Review(29 Nov 2019)

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

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

□ Ice Age

  ㅇ Difficulty bomb delay HF
    - James mentioned that inside of the retargeting algorithm that helps keep blocktimes stable for Ethereum, there is something called the Ice Age built in that, after every 100,000 blocks, it increments up. He also urged discussion of EIP-2384, saying that this has already affected block time over the past three weeks and that we should postpone it.
    - In response, Martin made some suggestions; The first is to carry out the Ice Age delay HF according to EIP-2384, the second is to linearly increase the difficulty level, and the third is to eliminate the difficulty bomb.
    - Peter pointed out that the ice age was coming really fast, and he hoped for a solution in early January and said the version should be released next week in consideration of the year-end holidays.
    - James stressed that the postponement was already community-approved, and that more time and opinions would be needed if there were additional changes.
He also said that the block number for the Ice Age smoke HF is 9,200,000 and the timing is expected to be Jan. 5 or 6.

□ Approving EIP

  ㅇ Last call of EIPs
    - Alex said in EIP repo that the last call is in a very special status in the presence of RSS feeds. In other words, he explains that if something is moved into Last Call,
it's going to show up in the RSS feed and maybe some new people are going to be notified about it, and they could find something this late in the process.
    - Hudson said it would be easy to do Last Call and switch it to final but would be good to pop up into the feed and then it will become final. Alex agreed with his mention.

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
    - James는 이더리움의 블록타임을 안정적으로 유지하는데 도움이 되는 난이도 조정 알고리듬이 있는데, 이것을 '빙하기'라고 하며 100,000블록마다 난이도를 증가시키는 '난이도 폭탄'이라고 소개했다. 또한 그는 이미 지난 3주동안 이것은 블록타임에 영향을 끼쳤기 때문에 우리는 이것을 연기해야한다고 말하면서, EIP-2384에 대한 논의를 촉구했다.
    - 이에 Martin은 몇가지 제안을 했다; 첫째는 EIP-2384에 따라 빙하기 연기 HF를 감행하는 것이고, 둘째는 난이도를 점진적으로 높이는 것이고, 셋째는 난이도 폭탄을 없애는 것이다.
    - Peter는 빙하기가 정말 빨리 오고 있다고 지적하면서, 1월초에 해결책이 나오기를 바랬고 그러려면 연말연시를 감안하여 해당 버전을 다음주에 출시해야한다고 말했다.
또한 그는 여태까지 빙하기 연기 HF를 했으므로 한번 더 하는 것은 어렵지 않다고 첨언했다.
    - James는 이번 빙하기 연기는 이미 커뮤니티가 승인한 것이고, 추가 변동이 있다면 더 많은 시간과 의견이 필요하다고 역설했다. 또한 그는 빙하기 연기HF의 블록넘버는 9,200,000이고 시점은 1월 5일 또는 6일로 예상된다고 말했다.
    - Martin은 빙하기 연기에 대한 EIP-2384와 빙하기 연기 HF에 대한 EIP-2387을 최종승인으로 지정한다고 말했다.

□ EIP 승인 관련

  ㅇ EIP의 최종승인(Last call)
    - Alex는 EIP 보고에서 최종승인은 RSS피드가 있다는 점에서 매우 특별한 위치에 있다고 말했다. 즉, 최종승인이 되면 RSS피드에 나타나고 사람들이 거기서 뭔가를 발견할수 있다는 게 그의 설명이다.
    - Hudson은 최종승인없이 바로 승인확정하는 방법이 있으나 현행대로 최종승인을 유지하는 것이 낫다고 말했고 Alex도 그에 동의했다.

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

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

# Ravencoin Devs Meeting(22 Nov 2019) 

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

□ Analysis of the meeting by subject 

 ㅇ Current status and targets of development
  - Someone asked about updates (with regard to testing restricted assets, messaging etc.), and Tron answered that we are on target for December but not much either positive or negaive feedback yet. He also added The protocol part is done on testnet but the client display for messaging needs to be in Win/Mac/Linux/iOS/Android/Web clients.
  - When asked if Dividends feature is available, Blondfrogs replied that it is on testnet and is available when it is released on the mainnet. Tron said he will soon write Medium article on how to use Dividends on testnet. 
  - Blondfrogs said we are not be sure about December release, but once the features are fully secred, it will be released. And he said the next target on the roadmap will be voting, adding that for now,  we will be focusing on building on top of the current features to make them more accessable and GUI support.

 ㅇ Mailing list
  - Tron explained that he is currently sending Ravencoin-related mail through the mailing list, and that everyone can subscribe to different types of mail, such as updates and development, and advised him to check for spam filters if the mail did not arrive even though one already subsribed. 
   ※ Subscribing for dev : https://cdn.forms-content.sg-form.com/96861d25-0b10-11ea-b9d3-a63f003f1823
      Subscribing for updates : https://cdn.forms-content.sg-form.com/8ec7a872-d599-11e9-ada2-7a44cc589a29

 ㅇ Bug Bounty*
  - Blongfrogs added that bounty fund was donated by Medici Venture, saying that if a bug is found that breaks consensus rules, a payout will sent in RVN to an address given to us by the Bug issuer.
  * Bug bounty :  the thing that provides rewards to hackers who discover vulnerabilities such as bugs by hacking into their services and products

 ㅇ  Improving block verification*
  - eureka suggest that we could validate a fast hash for indexing in every block and need to change block header format to do so, He also said that there are other options to reduce PoW impact for mobile wallets too, adding that a quick hash can be added for block indexing and PoW hash can be tested in a sampled manner, say only 1% of blocks have to run full PoW test.
  - Tron said that SPV** wallet validates the blocks it is given right now and only a few SPV wallet such as iOS and Android version of RVN Wallet exist now. Blondfrogs also explained that that is something we could do, however, at the moment would require us to increase the header size invaliding all current mining algos written for GPU as they require an 80 bytes version to be used. 
   * Blockhash: putting version, time, muckroot, target, nonce, and previous block hash in a block and converting its transaction details and information into a hash
   ** Simplified Payment Verification(SPV) : A node that stores block and transaction verification itself(Full nodes) by storing all blocks from genesis block 
to the current block, which is 1 to 3% as compared to a full node without its transactions, but requires the help from full nodes when verifying transactions

 ㅇ Outlook on securities tokens issue
  - Someone asked when companies can issue securities in Raven, Tron said that it's up to companies to use it and we're building the tool.

 ㅇ Date for next network upgrade
  - Tron said Dec 18th is a target date for activating the block count for feature activation. 
And Blondfrogs said It is hard to pick a specific date for features we are shooting for December for feature voting adding that we will wait until we feel all features are secured and tested.

□ Personal Comments

 ㅇ Towards New Network Upgrade
  - Mainnet implementations such as restricted assets and messaging functions, which are currently on testnet, are not far off. If testnet, bug bounty, and voting are successfully completed, Raven will be upgrated and then climb up to the next level by the end of the year. FYI, I am using thw word 'Network upgrade' in consideration of the fact that the term 'Hard fork' is identified with the chain splitr and airdrop. In fact, a fork means copying a software(SW) and develop an independent software.
  - Ravencoin was also forked from bitcoin, and most hardforks aim to release a new version with part of the algorithm changed. This means that most of them are network upgrades, except in cases such as Ethereum Classic(ETC) and BitcoinCash(BCH) that result from conflicts of interest between core and mining groups.
   - Anyway, Ravencoin will be upgrated by voting through BIP9 in December. BIPs stands for Bitcoin Improvision Proposals and BIP9 defines how much a proposal like upgrading to a new version will be supported and applied on the network. Ravencoins also have RIPs(Ravencoin Implementation Proposals) and RIP2* corresponds to category BIP9 of Bitcoin.
   * RIP2 Description: https://github.com/ravenproject/rips/blob/master/rip-0002.mediawiki

  - In accordance with this BIP9/RIP2, miners are asked to signify whether they support the new upgrade by inserting certain version bits. It's pretty much like a form of voting, which usually requires four steps to get it done. 

   1) Define : It is defined that what versionbit will be inserted in the block and block period(from what block to what block). FYI, if you receive more than 65% support under RIP2, testnet will be activated, and if you receive more than 80% support, mainnet will be activated.
   2) Start : When various criteria are defined in Define phase, a vote to confirm support begins. FYI, voting takes place from N block to N+2016 block considering the adjustment of the mining difficulty every 2106 block.
   3) Lock-in : If 80%(or 65%) of support is received, a new upgrade is locked in during another 2016 block period for the release of mainnet(or testnet). 
   4) Activate : If there is nothing unusual in Lock-in phase, the network upgrade is completed.

   - We hope that voting described above will take place sometime in December and Raven will soar high and high in 2020.

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.

(한국어 버전) 

□ 소재별 회의 내용

 ㅇ 개발 현황 및 목표
  - Tron은 '(제한자산, 메시징 기능 등의 테스트 및 메인넷 구현 관련) 최근 동향'에 대한 질문에, 아직 좋은쪽으로든 나쁜쪽으로든 많은 피드백은 없지만 여전히 12월을 목표로 하고 있다고 답했다. 또한 그는 프로토콜 부분에 대한 테스트는 완료되었으나 메시징 기능을 위한 클라이언트 관련 작업은 진행중이라고 첨언하였다.
  - Blondfrogs는 '배당(Dividends) 기능이 사용가능한가'에 대한 질문에, 해당 기능은 테스트넷에서 검토중이며 메인넷에 출시되면 사용가능하다고 답변하였다. 그리고 Tron은 테스트넷에서 배당(Dividends) 기능 활용하는 방법에 대한 Medium 기사를 작성할거라고 말했다.
  - Blondfrogs는 12월에 출시를 장담할수는 없지만, 기능들이 충분히 검증되면 출시할거라고 말했다. 그리고 그는 로드맵상 다음 타킷은 투표(Voting) 기능이 될거라고 말하면서, 현재로서는 지금 구현하려는 기능들에 대한 접근성과 인터페이스 지원을 향상시키는데 주안점을 두고 있다고 덧붙였다.

 ㅇ 메일링 리스트(Mailing list) 
  - Tron은 현재 메일링 리스트를 통해 레이븐코인 관련 메일을 보내고 있으며, 업데이트, 개발 등 서로 다른 유형의 메일을 구독할수 있다고 설명하면서, 혹시 메일신청을 했음에도 메일이 도착하지 않았다면 스팸필터 여부를 확인하라고 조언하였다.
  ※ 개발 관련 메일 신청 : https://cdn.forms-content.sg-form.com/96861d25-0b10-11ea-b9d3-a63f003f1823
     업데이트 관련 메일 신청 : https://cdn.forms-content.sg-form.com/8ec7a872-d599-11e9-ada2-7a44cc589a29

 ㅇ 버그 바운티(Bug bounty)*
  - Blongfrogs는 합의규칙을 무너뜨리는 버그가 발견한 자의 주소로 일정량의 레이븐을 보상으로 지급될거라고 말하면서 그 보상펀드는 메디치벤쳐사로부터 기부받았다고 첨언하였다.
  * 자사 서비스와 제품을 해킹해 버그와 같은 취약점을 발견한 해커에게 포상금을 지급하는 제도
   ※ 버그바운티 정보 : https://github.com/RavenProject/Ravencoin/wiki

 ㅇ 블록검증 개선
  - eureka는 모바일 지갑에 있어 PoW 영향력을 줄일수 있는 방법이 있다(필자주: 더 나은 알고리듬 설계를 위하여 ASIC저항, 실행난이도, 모바일과의 호환성 등을 감안해야하는데 이때 모바일에서의 블록과 트랜잭션 검증을 위해 더 간단하면서 채굴의 영향을 덜 받는 방법을 찾는 노력이 필요하다)며, 블록헤더 포맷을 변경함으로써 모든 블록에 인덱싱작업을 하면 더 빠른 블록해시* 검증이 가능하다고 말했다.
  - 이에 Tron은 블록해시 검증을 위해서는 SPV**지갑이 필요한데 (레이븐코인 생태계에서는) iOS 및 안드로이드 레이븐코인 지갑과 tZero지갑과 같은 SPV지갑이 존재한다고 말했다. 또한 Blondfrogs는 그 제안을 구현하는 것은 가능하지만 현재 블록헤더 크기를 높여야하는 문제가 있다고 설명하였다.
   * 블록해시(Blockhash) : 버전, 시간, 머클루트, 타겟, 논스, 이전 블록해시를 하나의 블록에 담아 거래내역과 정보를 해시로 변환한 값
   ** SPV(Simplified Payment Verification) : 제네시스 블록부터 현재 블록까지 모든 블록을 저장하여 블록 및 트랜잭션의 검증을 자체 수행하는 풀노드(Full nodes)와는 달리
트랜잭션을 제외한 블록헤더만을 저장한 노드로 풀노드 대비 1~3%의 크기를 가져 휴대성이 높지만 트랜잭션 검증때 풀노드의 도움이 필요함

 ㅇ 증권토큰발행 전망
  - Tron은 '언제쯤 회사들이 레이븐으로 증권토큰발행이 가능한가'에 대한 질문에, 그것은 회사들에게 달려있는 문제라면서 우리는 그것을 위한 도구를 만들뿐이라고 말했다.

  ㅇ 차기 네트워크 업그레이드 날짜
    - Tron은 새로운 기능을 메인넷에 구현할 네트워크 업그레이드(=하드포크)를 위하여 12월 18일에 투표를 진행할것이며, Blondfrogs는 날짜를 확정짓기는 어렵지만 모든 기능이 검증되고 테스트하기 전까지 기다릴것이라고 말했다.

□ 개인 논평

 ㅇ 새로운 네트워크 업그레이드를 향하여 
  - 현재 테스트넷에서 검증되고 있는 제한자산, 메시징 기능 등의 메인넷 구현이 머지 않았다. 테스트넷 검증, 버그바운티, 투표 통과 등이 잘 이루어진다면 연내에 레이븐의 새로운 도약이 실체화 될것이다. 그 도약을 위해 또한번의 하드포크가 시행될 예정이며, 참고로 필자는 하드포크라는 용어가 체인분기 및 에어드랍과 동일시되는 실정을 감안하여 네트워크 업그레이드를 사용하고 있다. 원래 포크라는 것은 하나의 소프트웨어(SW)를 베껴 독자적인 소프트웨어를 개발하는 것을 의미한다.
  - 레이븐코인 역시 비트코인을 포크하여 나왔고, 대부분의 하드포크는 알고리듬 일부가 변경된 새로운 버전의 출시를 지향한다. 즉, 특정 거래소와 채굴집단의 모종의 거래를 통해 나온 이더리움클래식(ETC), 코어집단과 채굴집단 간 이해충돌 때문에 나온 비트코인캐시(BCH) 등과 같은 경우를 제외하고는 대부분 네트워크 업그레이드라고 볼수있다.
  - 어쨌든 레이븐코인은 12월 중 새로운 네트워크 업그레이드를 위하여 BIP9를 통한 투표를 진행할것이다. BIP는 Bitcoin Improvement Proposals(비트코인 개선안)의 약자로 BIP9는 새로운 버전으로의 업그레이드와 같은 제안이 네트워크에서 얼마나 지지받고 어떻게 적용될건지에 대해 정의된것이다. 레이븐코인 역시 RIP(Ravencoin Improvement Proposals, 레이븐 개선안)이 있으며 RIP2*가 비트코인의 BIP9 격에 해당한다.
   * RIP2 설명 : https://github.com/ravenproject/rips/blob/master/rip-0002.mediawiki

  - 이 BIP9/RIP2에 따라서 채굴자들로부터 새로운 업그레이드에 대한 지지의사를 묻는데 그 방법으로 블록헤더에 찬반여부를 표현(Signaling)하게 하고 그 업그레이드가 얼마나 지지받는지 확인한다. 일종의 투표방식인데, 이 투표를 위하여 보통 4단계가 필요하다.
   1) Define단계 : 지지여부(Signaling)를 위하여 블록헤더에 심을 버전비트를 정하고, 몇 블록부터 몇 블록까지 지지여부를 확인할것인지 정의한다. 참고로 RIP2에 따라 65% 이상의 지지를 받으면 테스트넷이 활성화되고, 80% 이상의 지지를 받으면 메인넷이 활성화된다.
   2) Start단계 : Define단계에서 여러 기준이 정의되면 지지여부를 확인하는 투표가 시작된다. 참고로 2106블록마다 채굴난이도가 조정되는 것을 감안하여 N블록에서 N+2016블록까지 투표가 진행된다.
   3) Lock-in단계 : 80%(또는 65%)의 지지를 받으면 메인넷(또는 테스트넷) 출시를 위해 또다른 2016블록기간동안 새로운 업그레이드를 걸어잠근다.
   4) Activate단계 : Lock-in단계에서 특이사항이 없으면 비로소 메인넷이 활성화되면서 네트워크 업그레이드가 완료된다.

  - 앞서 설명한 투표가 12월 중에 실시될 예정이며 2019년이 지나기전에 레이븐코인의 도약의 발판이 생겨 2020년에 새로운 성과가 창출되기를 기대해본다.

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

[Libra] 리브라의 최근백서로 본 비전과 야망(Libra's Vision & Ambition by its recent whitepaper) v1.0

□ 리브라 최신 동향

  ㅇ 리브라 합의 백서(Version 3) 
    - 11월 9일 리브라 협회는 새로운 버전의 리브라 합의프로토콜 백서(이해 '백서')를 공개하였고, 2가지 주요 개발사항을 포함하였다.
     1) 백서에 담긴 내용을 코드베이스에 구현하며, 앞으로도 코딩구현에 매진한다.
     2) 향후 리브라 개발팀이 공유할 몇가지 개선사항과 확장에 대한 로드맵 내용을 포함한다.
     ※ 이번 버전의 리브라 백서 : https://developers.libra.org/docs/assets/papers/libra-consensus-state-machine-replication-in-the-libra-blockchain.pdf

  ㅇ 리브라 합의프로토콜 개요
    - 백서에는 '핫스터프(HotStuff)'를 기반으로 한 라운드 구조의 합의 프로토콜에 대한 설명이 담겨 있으며, 그 라운드는 연속된 3개의 블록에 걸쳐 진행된다.
< 리브라의 블록생성 확정 구조 >

    - 또한, 백서는 더욱 복잡하고 세련된 상황에서도 비잔진공격(또는 포크)에도 불구하고 안전성을 유지하는 시나리오에 대해서도 다룬다. 아래사진중 왼쪽은 커밋(=블록확정)된 블록으로부터 한번의 포크가 발생된 시나리오를 가정하며, 아래사진 중 오른쪽은 커밋된 블록으로부터 포크가 발생했지만 그 포크된 체인에서 아직 한번도 커밋되지 않은상황에서 또한번의 포크가 발생된 시나리오를 가정하였다.
< 리브라 블록생성 중 포크되는 상황 시나리오 >

  ㅇ 지난 5개월간의 성장기
    - 2019년 6월 18일 리브라 프로젝트를 발표한 이후 5개월동안 다음과 같은 성과를 이뤘다.
     1) 우리는 전세계에서 개발자들을 불러모으고 개발인프라를 구축하였다.
     2) 9월 17일 테스트넷을 리셋한 이후, 51,000건 이상의 트랜잭션을 기록하였다.
     3) 온라인 개발자 커뮤니티, 깃헙 등을 통합하여 개발자들이 리브라 프로젝트팀과 협업할수있도록 단순화하였다.
     4) 문서와 기술 블로그를 꾸준히 게시하여 개발자들로 하여금 리브라의 배경과 기술에 대하여 안내하였다.
     5) 버그바운티 프로그램을 출시하여 개발자들로 하여금 버그를 더빨리 발견하고 고칠수있게 하였다.
    - 리브라 프로젝트 성공을 위하여 더 많은 사람들을 불러모아 커뮤니티를 확장시킬것이며, 우리는 모든 개발자들이 리브라 생태계안에서 이슈, 도전, 기회에 대한 토론을 할수 있도록 다양한 이벤트를 시행할것이며, 아래와 같은 사항도 로드맵에 포함시켜 추진할것이다.
     1) 리브라 노드를 유지하는 방법
     2) 리브라 지갑을 구추하는 방법
     3) 리브라 네트워크를 확장시키는 방법
     4) 리브라 지갑의 상호운용성
     5) 사전메인넷의 확장
    - 리브라 네트워크의 기능을 더 빨리 검증하고 전세계 개발자들에게 더 쉬운 접근권한을 제공하기 위하여 우리는 메인넷 출시 이전에 '사전메인넷(Pre-mainnet)'을 가동중이다.

□ 개인 논평 

  ㅇ 리브라의 비전과 야망을 백서와 코드베이스에 담다 
    - 본문의 소개한 내용은 리브라 공식 홈페이지(https://developers.libra.org/)에서 볼수 있으며, 왠만한 블록체인 지식이 없으면 이해하기 상당히 난해할것이다. 하지만 필자는 '유망프로젝트의 기술개발팀과 일반 커뮤니티의 가교 역할'을 자처하는 만큼 본인의 지식과 통찰력에 따라 리브라가 무엇을 하고 있고 또 무엇을 노리고 있는지 안내하겠다.

   < 리브라의 합의 프로토콜에 대한 고찰 >
    - 우선, 리브라의 합의 프로토콜에 대해 살펴보자. 소위 LBFT(Libra-Byzantine Fault Tolereance)는 네트워크 장애모델 중  가장 고도화된 모델인 '비잔틴 장애허용(Byzantine Fault Tolereance, 이하 'BFT')모델을 기반으로 하고 있으며, 특히 최신 합의 프로토콜인 '핫스터프(HotStuff)'를 차용하였다. 핫스터프는 2018년 3월에 발표(https://arxiv.org/pdf/1803.05069.pdf)된 최신 합의 프로토콜로, 기존 BFT계열의 합의 프로토콜이 합의가 이뤄지지않고 블록을 확정하기 위한 과정만 무한반복하여 거래처리속도(TPS)를 저하시키는 문제를 개선하기 위해 나왔다. 이게 무슨 외계어냐고 하실까봐 좀 더 쉽고 세부적으로 설명해보겠다.
< 장애-생존성-안전성의 삼중고 >

    - 우리가 흔히 얘기하는 블록체인 합의 프로토콜은 일정수준의 장애를 허용(Fault Tolerant)하면서도 생존성(Liveness)과 안전성(Safety)의 균형을 유지하는게 매우 중요하다. 참고로 '생존성'은 악의적인 노드가 일부 존재하더라도 블록생성을 지속시키는 특성이고, '안전성'은 악의적인 노드가 일부 존재하더라도 합의에 도달하도록 보장하는 특성이다. 여튼 생존성과 안전성의 균형을 유지하기 위한 방법으로 크게 3가지 유형이 존재한다.

    ※ 3가지 유형을 살펴보기전에 필자의 지난 글을 같이 보시라
     - 작업증명방식과 나카모토 합의알고리듬 : https://www.satoshicode.com/2019/01/consensus-proof-of-work-satoshis-vision.html
     - 생존성, 안전성, 동기성에 대한 필자의 분석 및 논평 글 : https://www.satoshicode.com/2019/01/technology-and-flp-impossibility.html

     1) 노드 간 메시지가 정해진 시간 안에 전달되는 '동기성(Synchoronous)' 유형
      이것의 대표적인 예가 비트코인인데, 비트코인의 합의 프로토콜 중 '체인선택규칙''나카모토합의방식(Nakamoto Consesns)'으로, 이는 '이전의 블록보다 더 많은 블록을 생성하여 더 긴 체인을 만들면 언제든지 기존에 합의된 블록과 체인을 다른 블록과 체인으로 대체할수 있는 특징을 갖고 있다(필자주: 작업증명방식(PoW)는 비트코인 합의프로토콜의 '블록선택규칙'에 해당한다). 즉, 비트코인은 이 특징때문에 매우 흔치않은 '생존성에 무게중심을 둔 장애허용모델'인데 상대적으로 약화된 안정성을 보완하기 위하여 10분이라는 시간을 두어 노드 간 메시지를 주고받고 검증할 시간을 두었다.

     2) 노드 간 메시지 전달이 정해진 시간에 구속받지 않는 '비동기성(Asynchoronous)' 유형
     이 유형은 동기성 유형이 메시지 전달 시간이 고정된 특성때문에 거래처리속도(TPS)에 한계를 보여 제안된 대안 유형이다. 대표적인 예가 아이오타인데, 단순 노드수 제어방식에서 벗어난 DAG방식*을 도입하고 DAG기반의 탱글**이라는 알고리듬을 사용한다.
     * DAG(Directed Acyclic Graph) : 기존의 선형체인방식을 탈피해 트랜잭션 자체를 트리 방식의 단방향 링크 리스트로 먼저 저장하고 나중에 합의하는 방식.
     **탱글(Tangle) : DAG를 기반으로 하는 새로운 알고리즘으로서, 네트워크 참여가 트랜잭션을 발생시키는 동시에 이전 트랜잭션을 확인하는 검증자가 됨. 새로운 거래를 하기 위해서는 반드시 이전에 진행되었던 2개의 거래내역을 확인하고 검증을 진행해야 함. 전체 트랜잭션 개수가 늘어날수록 네트워크 참여자 및 검증자들이 증가하면서,
시스템의 안전성과 확장성(Scaliability)이 더욱 커짐.
< 아이오타의 탱글 모형 >

     3) 노드 간 메시지 전달이 정해진 시간안에 이뤄지지만 그 정해진 시간이 어느정도인지 모르는 '부분동기성(Partial synchronous)' 유형
      이 유형은 안전성을 확보하면서도 생존성을 포기하지 않는 일종의 타협안이다. 대표적인 예가 코스모스의 텐더민트인데, 라운드 당 2번의 투표과정을 두고, 첫번째 투표에서 총 노드 중 2/3이상이 사전투표를 하고 두번째 투표에서 역시 2/3이상이 확정투표(=커밋)를 하면 블록이 생성되는 메커니즘이다(필자주: 사실 첫번째 투표가 실패해도 두번째 투표에서 커밋이 되면 블록은 생성된다).
< 코스모스 텐더민트의 블록생성과정 >

    - 멀리 돌아왔지만 리브라가 차용하는 '핫스터프 프로토콜'은 앞서 설명한 부분동기성 유형인 코스모스 텐더민트보다 라운드 당 1단계 투표과정을 추가한 방식이다. 그렇게 바꾼 이유는, 아무리 부분동기성 유형이 안전성을 중심에 두고 생존성을 끌어올렸더라도, 여전히 생존성이 떨어지기 때문에 생존성을 보다 더 끌어올릴 필요가 있었기 때문이다. 달리 말해, 2단계 투표과정 방식에서는 첫번째 투표가 실패해도 두번째 투표가 성공하면 블록은 생성되지만 두번째 투표마저 실패하면 또다시 한 라운드를 기다려야하므로 TPS에 악영향이 간다. 그래서 3단계 투표과정을 두어 첫번째나 두번째의 투표가 성공하든 실패하든 세번째 투표가 (언제가 될진 모르지만) 성공하면(=커밋되면) 블록이 생성된다. 필자가 이해를 돕기위해 다소 축약하여 설명하였지만, LBFT는 부분동기성을 띠는 대부분의 전통적인 BFT보다 블록생성합의에 더 큰 융통성더 나은 생존성-안전성 간 균형성이 있다고 요약할수 있다.

   => (리브라의 비전) 리브라 측은 '우리는 생존성, 안전성, 확장성 면에서 어디에도 꿀리지 않는 최첨단 기법을 활용한 합의 방식을 지닌 네트워크를 출시하려고 한다'라는 당찬 비전을 이번 버전의 백서를 통해 보여주고 있다. 

   < 리브라 백서 행간에 담긴 야망 >
    - 필자는 지난 6월 페이스북이 리브라를 공표하기 전부터 국가주도의 토큰 발행을 지켜보면서 언젠간 민간기업 주도의 토큰 발행, 그것도 변동성이 없는 스테이블 코인이 나올거라고 예상하였다. 때마침 리브라가 세상에 6월 공개되었고 그때부터 리브라의 동향을 주시하였다. 그 일환으로, 이번 리브라의 이번 백서를 통해 필자가 느낀 리브라의 야망을 풀어보겠다.

     ※ 그전에 필자가 지난번에 쓴 리브라 관련 분석 및 논평글들을 먼저 읽어보시라
      - '디지털 위안'과 '페이스북 리브라' : https://www.satoshicode.com/2019/09/article-digital-yuan-and-facebook-libra.html
      - 페이스북의 리브라, 출시 막을수 없을것 :  https://www.satoshicode.com/2019/09/news-facebooks-libra-might-be.html
      - 리브라 개발 업데이트(9월)-로드맵#1 : https://www.satoshicode.com/2019/10/libra9-1-v10.html

    - 필자가 존경하는 미국의 경제학자이자 오스트리아 학파로 유명한 머레이 로스바드(Murray Rothbard, 이하 '로스바드)는 자유경제시장경제를 설파한 인물로, 1970년대 이미 '정부가 우리의 돈을 위해 무엇을 했는가(What Has Government Done to Our Money)라는 책을 통해 '역사적으로 돈은 정부가 통제하는 최초의 것들 중 하나였고 18세기와 19세기의 자유시장혁명조차 화폐영역은 영향이 없었다고 지적하면서 이제는 돈에 대한 근본적인 관심을 가질때가 됐다'고 명시하였다.
    - 굳이 로스바드까지 거론하지 않더라도, 민간기업이 현존하는 명목화폐와 공존 또는 경쟁하기 위한 시도는 이미 여러번 있었다. 그 사례들 중 하나가 Gold & Silver Reserve이 1996년부터 2009년 사이에 운용한 E-gold(이하 '이골드')로, 이는 1972년 닉슨쇼크 이전의 미국 달러처럼 금과 일정비율로 연동되는 화폐이자 화폐시스템이었다. 결국에는, 미국 연방정부가 2008년 이골드를 돈세탁과 면허없이 돈을 전송하는 행위를 빌미로 고발하였고, 이후 이골드의 어필과 노력에도 고객수가 급감하면서 생태계가 무너졌다. 반면 20억 이상의 회원을 보유한 페이스북이 주도한 리브라는 여러 국가화폐를 묶거나 단일 국가화폐를 기반으로 할 계획이라고 말한다. 인류 역사상 가장 오래 검증되고 매력적인 금을 연동한 이골드는 자금세탁과 국가화폐에의 악영향을 빌미로 실패한 마당에, 페이스북의 리브라는 아예 대놓고 국가화폐와 연동한다. 이것이 내포하는 의미는 환율과 금리, 그리고 양적완화 등으로 세계금융을 쥐락펴락하는 파워 엘리트에 대항하는 것이며 이는 주요 국가들이 왜 유독 리브라에게 강력한 제재를 하려고 하는지에 대한 충분한 대답이 될수 있다(필자주 : 아직까지도 잘 모르겠으면 앞서 언급한 필자의 리브라 관련 필자글 3개를 다시 꼼꼼히 보시라. 아는게 힘이다. 공부하시라!).
    - 굳이 금까지 연동하지 않고 미국 달러 등과 연동하는 리브라는 우회하지 않고 로스바드가 지적했듯이 '이제는 돈에 대한 근본적인 관심을 갖겠다'고 하는 페이스북의 당찬 야망을 표현한것이고, 더 나아가 리브라토큰(LIT, Libra Investment Token)을 통해서는 분산금융 역시 진출하겠다는 야망까지 드러낸다. 실제로 이번 버전의 백서상에

     '인터넷과 모바일 광대역통신의 등장은 지식, 무료 통신, 광범위한 저비용, 
     더 편리한 서비스를 제공하면서 전 세계적으로 수십억 명의 사람들을 연결했다. 
     이러한 연결은 또한 더 많은 사람들이 금융 생태계에 접근할 수 있게 했다. 
     그러나 이러한 진전에도 불구하고, 금융에 대한 접근은 서비스는 
     여전히 그것을 가장 필요로 하는 사람들에게 제한되어 있다'

    라고 명시되어있다. 이것의 행간을 읽으면 '아, 인류 역사상 혁명되지 않는 영역이 화폐영역인데, 우리밖에 나설 자가 없네. 이것은 어쩔수 없는 우리의 운명이다!'라고 천명하는 것과 다름없다.

   => (리브라의 야망) 페이스북이 주도하는 리브라는 어떠한 형태로든 나올 가능성이 크며, 만약 출시된다면 화폐발행범위는 다른 민간집단은 물론 개인에게까지 넓혀질것이라고,필자는 확신에 가까운 판단을 하는 바이다. 

    - 작성하다보니 너무 장황한 내용이 되어버렸지만(그래도 나름대로 줄여서 작성한거다), 이번에 리브라 공식 홈페이지에 공개된 2건의 최신 동향을 통해, 기술개발을 토대로한 '리브라의 비전'과 백서의 행간을 통해 풍겨나오는 '리브라의 야망'을 알아보았다. 리브라에 대한 흥미가 없어지지 않는한, 리브라의 동향에 대한 논평을 공유할것이며, 이것의 파급력이 큰만큼 여러분들도 관심을 가지기 바란다.

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

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

#75 Devs Meeting Review(15 Nov 2019)

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

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

□ Istanbul HF adoption

  ㅇ Preparing for Istanbul HF
    - Ethereum core devs encouraged all users to update their client to the current release to ensure they are ready for Istanbul on the 4th December 2019, Block # 9,069,000.
    - Hudson said James posted a call for assistance on the (Ethernodes Website)(https://www.ethernodes.org/istanbul) to reach out to the mining pools, infrastructure providers and exchanges to ensure they are updated to the latest version of their client.

□ Regarding EIP as eligible for Istanbul HF 

  ㅇ EIP-2348
    - Danno said that this EIP is a conglomerate of several EIPs that have been floating around for a while. And he added that the purpose of this EIP is to build a foundation primarily for multi-byte EVM instructions,
saying there is evidence that adding multi-byte code right now will break some executions and there are four basic features that we are combining into this EIP.
     1) To use the EIP-1702 structure to ensure all other options in this EIP are eligible for use.
     2) Use headers in the EVM options. It is essential that we should allow code to opt in to a new versioning scheme. This allows people to use old versions of Solidity to compile their mainnet code. It is more sustainable to combine the header and one of the opcodes from the EIP-615 which is the ‘BEGINDATA’ opcode.
     3) Fix invalid opcodes - by putting a wrapper around the EVM code we are saying that this is the only code that is executable and validate that code.
     4) When you deploy a contract there is a validation step to ensure each code point is actually a valid code point. If opcodes do not exist then that opcode is rejected. In the future that opcode may exists as a single or multi-byte opcode but we just don’t know that now. In this case the EVM would evaluate the opcode against the known opcode list and reject it. While we are at it we are adding in an option to do static jump validation.
    - In response, Wei believes this is a solved issue and he thinks this can be done using an extension and account versioning which in my opinion is much nicer than the code prefix.

    - Martin just wanted to discuss this whilst it should not require a hard fork, saying it will affect the infrastructure around testing and coherency how opcodes are named and its main reason I want to make this change is to rename SHA3 (0x20) to KECCAK256.
Another dev asked if this name change affect the debugging tools being used and Martin answered yes and said that is why I want to discuss it and correctly syncronise this change.

□ Discuss EIP improvement proposals(EIPIP)

  ㅇ What & How to discuss 
    - Hudson mentioned that a few people from the Ethereum Foundation, Ethereum Cat Herders and Ethereum Magicians are gonna hold a meeting next week to discuss improving the EIP process.
He also said that will include all aspects, including the requirements to get EIP editors, how we can recruit EIP editors, redoing EIP-1, how to make the process clear to outsiders.

Disclaimer: Since this post was written for the purpose of providing information for investment, please be careful in your investment decision. You cannot copy, distribute, or edit the contents without my permission because it was made based on my own judgment based on the reference data.

(한국어 버전)

□ 이스탄불HF 적용

  ㅇ 이스탄불HF 준비
    - 이더리움 핵심 개발자들은 클라이언트 담당자들에게 2019년 12월 4일 블록넘버 9,069,000에서 이스탄불HF가 이뤄질 수 있도록 최신 버전으로 업데이트하도록 권고했다.
    - Hudson은 James가 Ethernodes웹사이트를 통해 채굴장, 인프라제공업체, 거래소가 최신버전으로 업데이트하도록 지원요청 고지를 했다고 말했다.

□ 이스탄불HF 승인후보 EIP 관련

  ㅇ EIP-2348
    - Danno는 EIP-2348이 한동안 계류된 몇몇 EIP들의 묶음이라고 말하면서, 이것의 목적은 멀티바이트 EVM명령어처리를 위한 기반을 구축하는 거라고 설명했다. 또한 그는 현재 상태에서 멀티바이트 코드를 추가할 경우, 일부 실행이 중단된다고 지적하면서, 이것에 다음과 같은 4가지 기능이 있다고 말했다.
     1) 이 EIP의 모든 옵션을 사용가능 여부를 확인하기 위해 EIP-1702구조를 사용한다.
     2) 개발자로 하여금 EVM옵션에서 헤더를 사용케하고 새로운 버전 구조에서 최적화 코딩을 가능케한다. 이를 통해, 사용자는 솔리디티 버전을 그들의 메인넷 버전으로 컴파일 할 수 있다.
     3) 유효하지 않은 opcode를 수정한다.
     4) 스마트컨트렉트 배포시 실제로 유효한 코드 포인트인지 확인하는 유효성 검사를 하는데, 이때 EVM이 opcode에 대해 싱글 바이트인지 멀티바이트인지 확인한다.
    - 이에 Wei는 이 EIP은 불필요환 계층 변환이 필요하기 때문에, 이것보다 확장 및 계정버전을 활용하는게 더 낫다는 의견을 제시했다.

  ㅇ EIP-1803
    - Martin은 이 EIP가 하드포크가 필수가 아니라서 제대로 다뤄지지 않았다고 운을 띄웠다. 그러면서 그는 이것은 opcode를 명명하는 것에 대한 테스트와 일관성 인프라에 영향을 끼친다고 설명했고, 이것의 주목적은 SHA3(0x20)를 KECCAK256로 이름변경을 하는 것이라고 말했다. 이에 다른 개발자는 이름변경이 사용중인 디버깅 도구에 영향을 주는지 물었고, Martin은 영향을 끼친다면서 그것이 그 변경을 올바르게 추진하기위해 논의하고 싶은 이유라고 답했다. 

□ EIP 개선 제안 논의

  ㅇ 논의 방향
    - Hudson은 이더리움재단, 이더리움 캣허더, 이더리움 매지션의 몇몇 사람들이 EIP프로세스 개선에 대해 논의하기 위해 다음주에 회의를 열 예정이라고 소개했고,
이 회의에서 EIP편집자 모집방법 및 요구사항, EIP-1 재실행, 외부인에게 프로세스를 명확하게 하는 방법 등 모든 측면을 다룰거라고 말했다. 

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

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

# Ravencoin Devs Meeting(8 Nov 2019) 

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

□ Analysis of the meeting by subject

  ㅇ Discuss new anti-ASIC algorithm
    - Tron said he had read through X1MT-related paper, proposal for ASIC resistance algorithm written by whitefire990, and said it wasa  well researched document that analyzed ways it hard for ASICs. However, he worried about the feature of making a seed algo more dominant to trick ASICs because it will also add significant variance to the amount of time a block might take to mine. PlayHard also pointed out that although the documents are excellent, there is no mention of power consumption and recalculation is needed.
    - Whitefire990 explained that the paper is generally pushing for the X1MT variant which has constant hash rate per block, and only requires 1-2 nibbles from the block header. He also said if anyone deosn't like any of the variants suggested, then perhaps it is time you publish your own formal paper.

  ㅇ Mailing list
    - Tron said he a meeting on monday to evaluate SendGrid against running our own e-mail server, adding that the current mailing service is nothing more than a free trial. Moving up a level will cost $60/month, but increases cost by subscriber. Joemarket asked if we can use Raven Blockchain for the email server and Tron replied that is because the services are better.
    - WuKong suggested that we have to gather what info is needed into 'general news part' of the mailing list from community via telegram, discord etc. because my Raven supporters are not familiar even to basic things about Ravencoin and its mechanism. Then, DevJonPizza introduced his homepage(https://jon.network/forum), and also push suggested using helpdesk in discord or Ravenwiki that are existing communication channels.

  ㅇ Raven Foundation
    - Jeroz said we needed time and people to set up the foundation, and WuKong asked who would lead the Foundation. Many devs also wondered if there were any documents or articles about the foundation, and Tron said he'd love to see a proposal on what the Ravencoin Foundation does. Push said that if someone establishes Raven Foundation, a clear goal of the foundation is important, and a mechanism of funding it. perhaps this foundation could serve a first place that people can goto for free advice or
finding the right companies in ravencoin ecosystem.

  ㅇ Measures to prevent asset spam ads
    - Regarding measures to prevent asset-spam advertising discussed in the previous meeting, push proposed adding a button to apply the filter mentioned last time or to burn the address where it was sent.
    - Blondfrogs said we currently have a plan on building a machine for holding assets but this hasn't been completed yet.

  ㅇ Current status of testnet development
    - Blondfrogs said Messaging is built and running on testnet and GUI will come next, while Tron said that anyone can can develop Dividends feature which is in progress now with a script.
    - Bradar asked when Dividends feature would be on mainnet and Tron replied that it would be ready by the time Restricted Assets activates.

  ㅇ When next fork
    - Tron said we will use BIP9 to proceed with the next fork to apply the Restricted Assets, which is expected to be approximately 15th Nov, although it will depend on Bounty program, early next week. He also added that the BIP9, which is a soft fork rather than a hard fork, is a best way considering the previous hard fork.

□ Personal Comments

  ㅇ Where is long-term anti-ASIC algo
    - I participated in the recently created algo channel and continuously observed discussions of ASIC resistance method. Although I analyzed blockchain and cryptocurrency in my own way for about five years, I could somehow understand the design and direction of each proposed method. One of the methods is X1MT method mentioned in this meeting.
    - whitefire990 on the algo channel mentioned that the point of the document was to see what the limit is for X16R-style algorithms, saying he hope that the document would inspire new ideas, perhaps some of the ideas can be repackaged in a different way.
    - I was going to skip over the documentl at this point, but I don't think there will be very few people to understand it, so I'm going to summarize it in my own way, which is about 29 pages long. However, I want you to know that it takes a lot of effort and time for me to study and analyze new things every time and that I am willing to act as a bridge to the community.

  ㅇ Saving Private GPU in anti-ASIC battlefield
    - The intent of Whitefire990's paper is as follows. Maintain the same style and spirit as the X16R algo, while applying a transformation without developing an entirely new algo. In addition, the efficiency of the new algorithm proposal is contrasted with 28nm ASICs for the X11 algo and the 1080i GPUs.

   < Price-to-performance ratio of ASIC vs. X16S algo >
    - First of all, there are 16 optional algos in X16S. Subsequent to S is the basic 16 algo listing order itself, but the new algo listing order at each block creation time is random. Simply put, the order of the algo listing itself is set in the basic design, but the order of the algo listing from N block to the N+15 block is random. The simulation results are as follows, a price-to-performance ratio of ASIC vs. X16S algo is about 175 times higher.

   < Price-to-performance ratio of ASIC vs. X16R algo >
   ※ Click here to understand X16R principle(https://www.satoshicode.com/2019/05/blog-post_17.html)
    - This time, it is a simulation of ASIC resistance of X16R that was responsible for ASIC resistance of Raven before October 1, 2019. Unlike the X16S described earlier, the order of the algo listing changes for each block creation as well as for the basic design. At first glance, ASIC resistance is likely to be significantly higher because the S method is more random than the R method, but it is not indeed. The reason is in the order in which the block is selected. It means, after monitoring the random sequence of algo generated at every block creation for 100 million times, one of the 16 algos is often repeated continuously. In particular, the probability that one algorithm repeats five consecutive times is only 4.3%, and the probability that it repeats more than six consecutive times is almost zero.

    - Therefore, designing a chip with 'select and concentration' strategy that excludes
more than four consecutive times of a certain algo from the ASIC manufacturers increases efficiency and it can never be ignored. As a result, a price-to-performance ratio of ASIC vs. X16S algo is about 81 times higher.

   < Price-to-performance ratio of ASIC vs. X16RF algo >
    - X16RF, designed to solve the low replication probablity of certain algo shown in X16R, increases the continuity of a certain algo by extracting four additional digits from the blockheader. As a result, the probability of a certain algo coming out 12 times in a row has improved to about 8.6%. Due to this reason, a price-to-performance ratio of ASIC vs. X16S algo is about 27 times higher.

   < Price-to-performance ratio of ASIC vs. X1632RF algo > 
    - X1632RF is similar to X16RF described earlier, but there is a difference between the number of algos where 16 more algos can be selected during block creation. In fact, the complexity of ASIC design become higher and thus a price-to-performance ratio of ASIC vs. X16S algo is about 13.4 times higher.

   < Price-to-performance ratio of ASIC vs. X20RVS algo >
    - X20RVS has 20 selectable algorithms, and the order of the algos changes for each block creation. VS means something called Variable Sbox to increase complexity, which is never an attractive way for GPU. This is because ASICs are about 65.1 times higher than X20RVS GPUs in profitability, which is not much different from X16R. However, a price-to-performance ratio of ASICs vs. FPGA has been greatly reduced by about twice.

   < Price-to-performance ratio of ASIC vs. X1MT algo >
    - The last review is about X1MT, which includes Memory Translation(MT) as it is inferred from the name. The expected effects of this algorithm are as follows.
     1) It maintains nearly equal price-to-performance for GPU and FPGA
     2) It has the maximum amount of ASIC resistance of any variant suggested
     3) It can be calibrated to equalize/stabilize the network hash rate between blocks, allowing the difficulty adjustment algorithm to more easily maintain 60 second blocks
    - Noticeably, Memory Translation does not affect the hash rate of the GPU or FPGA at all, but ASICs have significantly reduced its performance. Based on the simulation results, a price-to-performance ratio of ASIC vs. X1MT-16 is 7.7 times higher, a price-to-performance ratio of ASIC vs. FPGE is only 2 to 5 times higer.

    - For your information, a price-to-performance ratio of ASIC vs. X1MT-32 is just 3.5 times higher. Compared to FPGA, a price-to-performance ratio is not much different.

    - Whitefire990 described at the end of the paper that X1MT-16 uses the same hash function as the X16R. A GPU programmer would only need to implement the scratchpad generation, and the memory transformation step, which would probably account for 3 days of work. X1MT-32 requires the same work, plus the implementation of MD6 and Hamsi-256 for which there is no existing GPU code. Further, X1MT-32 would require some ‘cut-and-paste’ from other GPU mining software such as Nexus and Sinovate, to paste together the remaining functions. A good GPU programmer could probably get X1MT-32 up and running in around 1 week.
    - As a result of a very simple explanation of his proposal, what we can see is that it is almost impossible to find a way to perfect anti-ASIC methods. In my opinion, what can beat ASIC is another ASIC. Nevertheless, Raven's deve team devised a new algorithm, X16R, to make it easier to mine Raven from the scratch and is still working to maintain the distribution of Raven mining. And the proposal we've reviewed are among the results. We hope that Raven's sustainable ASIC resistance method will emerge someday, and our community will also continuosly support its vision.

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.

(한국어 버전) 

□ 소재별 회의 내용

  ㅇ 새 ASIC저항 알고리듬 논의
    - Tron은 X1MT 관련 문서(algo채널에서 열띤 논의를 촉발한 whitefire990의 ASIC저항 알고리듬 제안서)를 읽었고 ASIC을 괴롭히는 방법들을 분석한 잘 조사된 자료라고 말했다. 다만, ASIC을 속이기 위해 시드(seed) 알고리듬을 보다 도드라지게 사용하는 설계는 블록생성시간에 유의미한 변수가 발생할수 있어 우려가 된다고 지적하였다. 또한 PlayHard는 문서는 훌륭하지만 전력소모에 대한 언급이 없으며 재산정이 필요하다고 지적하였다.
    - 이에 해당 문서작성자인 whitefire990은 블록당 해시속도가 일정하고, 블록헤더로부터 오직 1~2니블만 필요한 변수를 적용하고 있다(필자주: 전환에 어려움이 없고 현재 평균블록생성시간인 60초에 큰 영향을 주지 않는다는 의미)고 설명하였고, 재산정은 재산정이 필요한 사람이 하는게 좋다고 말했다.

  ㅇ 메일링 서비스
    - Tron은 독자적인 이메일 서버를 구축하기 위한 일환으로 SendGrid사와 미팅을 가졌다며, 현재 메일링서비스는 무료 체험판정도에 지나지 않는다고 말했다. 메일서버를 초기 구축시 매월 60$정도를 내야한다는 트론의 말에 Joemarket은 레이븐 블록체인을 활용하면 돈이 들지 않는데 왜 유료 이메일 서버를 사용하냐고 물었고, 이에 트론은 서비스 품질이 좋기때문이라고 답변하였다.
    - WuKong은 많은 레이븐 지지자들이 레이븐에 대해 잘 알지 못하기 때문에 텔레그램, 디스코드 등의 소통채널로부터 지지자들이 알고싶은 내용을 이메일 서비스 내용에 담아야한다고 요청하였다. 이에 DevJonPizza는 그런 소통채널을 만들수 있다며 그가 만든 홈페이지(https://jon.network/forum)를 소개하였고, push는 이미 존재하는 디스코드의 helpdesk나 레이븐위키를 소통채널로 활용하자고 제안하였다.

  ㅇ 레이븐재단 설립
    - Jeroz는 재단을 설립할 시간과 인력이 필요하다고 말했고, WuKong은 재단을 누가 이끌건지에 대해 질문하였다. 많은 참여자들 역시 재단 관련 문서나 기사가 있는지 궁금해했고, 트론도 레이븐재단에 대한 제안서를 받고싶다고 말했다. push는 누군가 레이븐재단을 설립한다면 명확한 목표와 자금조달방식이 중요하다며, 레이븐에 대한 조언과 레이븐 생태계에 적합한 회사를 찾을수 있는 곳이 되어야한다고 말했다.

  ㅇ 자산스팸광고 방지 대책
    - 지난회의에 논의된 자산스팸광고(필자주: 소량의 자산을 활용하여 광고메시지를 담아 전송하는 행위) 방지 대책에 대하여, push는 지난번 언급된 필터장치나 그 광고를 전송한 주소를 소각할수 있는 버튼을 추가하자고 제안하였다.
    - 이에 Blondfrogs는 현재 그러한 자산을 숨길수 있는 방식을 만드는 계획을 갖고 있다고 말했다.

  ㅇ 테스트넷 개발 현황
    - Blondfrogs는 메시징(Messaging) 기능이 테스트넷에서 테스트중이며, 이후 GUI가 나올것이라고 말했고, Tron은 배당(Dividends)기능이 개발진행중이라고 말하면서 누구나 스트립트를 사용하여 개발에 참여할수 있다고 말했다.
    - Bradar는 배당기능이 메인넷에 얹어지는 시기를 물었고, 제한자산(Restricted Assetes)이 메인넷에 올려질때쯤 배당기능이 준비될거라고 Tron은 대답하였다.

  ㅇ 차기 포크 논의
    - Tron은 제한자산(Restricted Assets)기능 적용을 위한 차기 포크를 진행하기 위해 BIP9을 활용할것이며, 그 시점은 다음주 초에 진행될 바운티프로그램에 따라 달라지겠지만 대략 11월 15일로 예상된다고 말했다. 또한 그는 지난 하드포크를 감안할때 (하드포크보다는 소프트포크로 진행될) BIP9방식이 최선이라고 첨언하였다.

□ 개인 논평

  ㅇ 지속가능한 ASIC저항 알고리듬을 찾아서
    - 필자는 최근 생성된 algo채널에 참여하여 알고리듬 개발자들의 ASIC저항 방식의 논의를 꾸준히 지켜봤다. 비록 5년가까이 블록체인과 암호화폐를 나름대로 분석했음에도, 필자는 전문개발자가 아니기에 완벽히 그들의 논의를 이해하지 못했지만 각 제안방식의 설계와 지향점은 충분히 이해할수 있었다. 그 방식들 중 하나가 회의에도 언급된 X1MT방식이다.
    - whitefire990은 algo채널에서, X16R스타일의 알고리듬의 한계와 새로운 스타일의 알고리듬의 필요성을 피력하면서, 그의 제안서가 새로운 아이디어들의 영감을 불어넣기를 바란다고 말했다(제안서 보기 https://drive.google.com/file/d/14ZYwpI-t6rnQ3I_SEZHvvDwe2yQUnTJ5/view)
    - 이쯤해서 얼렁뚱땅 넘어가려고 했지만 해당 제안서를 보는 사람도 적을것이고 그 제안서를 이해할 사람은 더더욱 없을것 같아서 29페이지에 달하는 논문수준의 글을 다행히 대부분 이해한 필자 나름대로 정말 간략하게 요약해보겠다. 다만, 블록체인 지식이 어느정도 있는 필자 역시 매번 새로운 것을 공부하고 분석하는데 '많은 노력과 시간이 들어간다는 사실'과 '커뮤니티와의 가교 역할을 하려는 필자의 의지'만큼은 여러분이 조금은 알아주셨으면 한다.

  ㅇ ASIC저항전에서 GPU일병 구하기
    - whitefire990의 제안서의 취지는 다음과 같다. 완전히 새로운 알고리듬을 개발하지 않고 변형을 가하면서, X16R알고리듬과 동일한 스타일과 정신을 유지한다. 또한, 새로운 알고리듬 제안을 검토할때 효율성이 입증된 X11알고리듬용 28nm ASIC채굴기와 1080Ti GPU채굴기와의 가성비를 대조한다.

   < X16S 알고리듬 대비 ASIC의 가성비 >
    - 우선 X16S이라는 알고리듬은 16개의 선택가능한 알고리듬이 존재한다. 그 뒤에 붙은 S는 기본적인 16개의 알고리듬 나열순서 자체는 고정이지만 매 블록생성때마다 새로 나열되는 알고리듬 나열순서는 랜덤이다. 쉽게말해, 기본설계상 알고리듬 나열순서 자체는 정해져있지만 N번째블록부터 N+15블록까지 생성시 나열순서는 랜덤이다. 그 시뮬레이션 결과는 다음과 같으며, 가성비는 X16S GPU대비 ASIC이 약 175배 높다.

   < X16R 알고리듬 대비 ASIC의 가성비 >
   ※ X16R원리 보기(https://www.satoshicode.com/2019/05/blog-post_17.html)
    - 이번엔 2019년 10월 1일 이전까지 레이븐의 ASIC저항을 담당했던 X16R의 ASIC저항 시뮬레이션이다. 앞서 설명한 X16S와는 달리, 기본설계상 알고리듬 나열순서는 물론 매 블록생성때마다 그 나열순서도 바뀐다. 얼핏보면, S방식이 R방식보다 무작위성이 높기때문에 ASIC저항성도 상당히 높아질것같지만 실제로는 그렇지 않다. 그 이유는 블록생성시 선택되는 16개의 순서에 있다. 무슨말이냐면, 매 블록생성시 무작위로 생성된 알고리듬 순서를 1억번 정도 모니터링한 결과 16개중 하나의 알고리듬이 연속 반복되어서 나오는 경우가 많지 않는다는 것이다. 특히 하나의 알고리듬이 5번 연속 걸리는 확률이 약 4.3%에 불과하고 6번 이상 연속 걸리는 확률은 거의 0%다.

    - 따라서 ASIC제조사 입장에서는 하나의 알고리듬이 5번 이상 연속나오는 경우를 배제하는 '선택과 집중'방식으로 칩을 설계하면 효율성이 그만큼 높아지며 그것은 절대 무시할수 없는 효과다. 그 결과, 가성비는 X16R GPU대비 ASIC이 약 81배 높다.

   < X16RF 알고리듬 대비 ASIC의 가성비 >
    - X16RF방식은, X16R에서 나타난 알고리듬의 낮은 연속성을 해결하기 위해 고안된 방식으로, 블록헤더에서 4자리를 추가 추출하여 알고리듬의 연속성을 높인다. 그 결과, 하나의 알고리듬이 연속해서 12번 나올 확률이 약 8.6%에 달할정도로 연속성이 향상되었다. 그 덕분에 가성비는 X16R GPU대비 ASIC이 약 27배 높다.

   < X1632RF 알고리듬 대비 ASIC의 가성비 >
    - X1632RF방식은 앞서 설명한 X16RF방식과 유사하지만 블록생성시 선택가능한 알고리듬 갯수가 16개 증가한 32개라는 차이가 있다. 실제로 그만큼 ASIC설계의 복잡성이 높아지는 효과가 있고, 가성비는 X16R GPU대비 ASIC이 약 13.4배 높다.

   < X20RVS 알고리듬 대비 ASIC의 가성비 >
    - 이쯤되면 알고리듬 이름만 봐도 대략적인 설계방식이 유추될것이다. X20RVS방식은 20개의 선택가능한 알고리듬이 존재하며, 기본설계상 알고리듬 나열순서는 물론 매 블록생성때마다 그 나열순서도 바뀐다. 그 뒤에 VS는 Variable Sbox라는 것을 도입하여 복잡성을 높이는 건데 GPU에 결코 매력적인 방식을 아니다. 그 이유는 가성비가 X20RVS GPU대비 ASIC이 약 65.1배 높기 때문이며 이는 X16R과 큰 차이가 없다. 다만, FPGA대비 ASIC의 가성비는 약 2배정도로 크게 낮추는 효과는 있다.

   < X1MT 알고리듬 대비 ASIC의 가성비 >
    - 마지막 검토대상은 X1MT으로, 이름에서 유추되듯이 메모리 변환(Memory Transform, MT)기법이 적용된다. 이 알고리듬의 기대효과는 다음과 같다.
    1) GPU와 FPGA에서 동일한 수준으로 가성비를 높인다.
    2) 어떤 조건을 적용해도 ASIC저항이 극대화된다.
    3) 블록 간 네트워크 해시 속도를 균등화/안정화하여 보다 쉽게 난이도 조정을 하게하여 60초 블록타임이 유지된다.
    - 주목할 점은, 메모리 변환과정은 GPU나 FPGA의 해시율에 전혀 영향을 미치지 않지만 ASIC은 그 성능이 현저하게 떨어진다는 점이다. 시뮬레이션 결과, 16개의 해시기능을 탑재한 X1MT-16대비 ASIC의 가성비는 7.7배에 그치고, FPGA대비 ASIC의 가성비는 2~5배다.

    - 참고로 32개의 해시기능을 탑재한 X1MT-32대비 ASIC의 가성비는 3.5배에 그치고, FPGA대비 ASIC의 가성비는 큰 차이가 없다.

    - whitefire990는 제안서 말미에, X1MT-16는 X16R과 동일한 해시함수를 사용하고 있고, 스크래치패드 생성기와 메모리 변환 작업만 하면 개발완료된다고 말했다(약 3일 소요). 또한, X1MT-32도 X1MT-16개발작업에 일부 알고리듬만 추가하면 개발완료된다고 말했다(약 1주 소요).
    - 그의 제안서를 정말 간단명료하게 설명한 결과, 우리가 알수 있는 사실은 ASIC을 완벽히 저항할수 있는 방법을 찾기는 거의 불가능하다는 사실이다. 이쯤되면 필자 생각에 'ASIC을 이기는 것은 더 나은 ASIC이다'라는 결론이 나올법하다. 그럼에도 레이븐 개발팀은 처음부터 레이븐을 더 쉽게 채굴할수 있도록 새로운 알고리듬을 고안하였고 현재도 레이븐 채굴보상에 대한 분산화를 유지하기 위해 노력중이며, 이번에 살펴본 제안서도 그 결과물들 중 하나이다. 이 제안서를 계기로 레이븐만의 지속가능한 ASIC저항방법이 나오길 바라며, 우리 커뮤니티도 그 과정을 묵묵히 지지해주기를 바란다.

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

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

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