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

# Raven 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주전 논평과 이번 논평에 걸쳐 설명했음에도 불구하고 아직 포크과정이 확실히 이해되지 않을수도 있다. 설령 이해되지 않는다해도 중요한것은 포크시점까지 커뮤니티의 일원으로서 그것에 대해 관심을 갖고 지지하는 것이다. 현실세계에서는 대부분의 국가에서 의회를 통해 대의민주주의를 시행하고 있는 것과 비교할때 네트워크 참여자들이 직접 투표하는 방식으로 해당 네트워크와 커뮤니티를 발전시키는 것은 매우 놀라우면서 어려운 일이다. 그 놀랍고 어려운 작업을 우리는 지금 하고 있다. 그 점이 바로 우리가 주요 기능이 메인넷에 구현될 차기 포크를 진지하게 대해야 하는 이유이자 책무이다.


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

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

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

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

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

# Raven 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건의 최신 동향을 통해, 기술개발을 토대로한 '리브라의 비전'과 백서의 행간을 통해 풍겨나오는 '리브라의 야망'을 알아보았다. 리브라에 대한 흥미가 없어지지 않는한, 리브라의 동향에 대한 논평을 공유할것이며, 이것의 파급력이 큰만큼 여러분들도 관심을 가지기 바란다.


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

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

# Raven 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저항방법이 나오길 바라며, 우리 커뮤니티도 그 과정을 묵묵히 지지해주기를 바란다.



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

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

#73 Devs Meeting Review(25 Oct 2019)

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



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

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

  <Istanbul HF Roadmap>
   - May 17th (Friday): IstanbulHF EIP soft deadline
   - July 19th (Friday): EIP implementation for clients
   - October 30th (number): Ropsten Testnet HF
   - December : Mainnet HF(=Istanbul HF)


□ Istanbul HF 

  ㅇ When HF
    - Dano suggested that the date be December 4th or 11th, and Tim added that gives six weeks to get ready. Hudson said the fork block number should be set through Gitter Chat, noting again that we all agree on Dec 4th.

    - Piper said some unforeseen thing could causes us to want to push back the fork schedule and in that case it would be delayed by four weeks. Danno also said that the reason why a four-week period is needed is because all the clients need to put the block number into their code, and then all the exchanges and node operators need to download that code and install that code. So I think four weeks at a minimum is what we should budget for that, adding at least four weeks is necessary. Hudson said we're decided on December 4th, with January 8th as a backstop.

  ㅇ EIP-2124 : Software version identifier for nodes
    - karalabe first proposed EIP-2124 in May, a mechanism that makes it easy for ethereum clients to identify the software version of the node(computer server) in use, but the reason we brought it up again is that we had an issue with Rockstone where there was a miner pushing the non-forked chain quite a lot, adding clients have a hard time following a non-majority chain.

     - James said he knows the changes made by EIP-2124 do not require hard-forking, but asked if a process such as EIP proposal and execution is necessary, and Karalabe said yes, and Piper explained that clients can roll it out today if they want to, because all users don't have to agree and it doesn't affect the network.

   ㅇ EIP-centric system
    - Hudson expected Ice Age before the Berlin HF, post-Istanbul HF and asked how it works, and Karalabe, Piper and Martin said the Ice Age is just another EIP-centric thing that gets solved.

    - The following discussion focused on "Is the eIP-centered system's fork appropriate?" followed by opinions from various devs. Tim suggested that we could commit to upgrading in six months with whatever is ready then. However, Karalabe said it makes sense to bundle them together and added, We tried to do half year or eight month hard forks originally. Then, Pooja suggested that we can target for a biannual upgrade without fixed period just depending upon the readiness of EIPs, naming this model as ''hybrid of time-bound and EIP-bound'.

    - Martin asked if there were volunteers who wrote the EIP for the ice age delay and Hancock volunteered as the coordinator for the next fork.

    - Alex pointed out that on the EIP-centric system, each EIP champion is only interested in sharing the idea and then expecting client developers to finish it off. And Hudson said that what is essentially important is that we find ways to motivate ourselves more in the EIP-centric system, and pointed out that the reason why we are less interested in EIPs is because now we have more resources that are in the hybrid technical/non-technical range, so they expect more people to do it for others.

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



(한국어 버전)

□ 로드맵(https://eips.ethereum.org/EIPS/eip-1679)

   <이스탄불 HF 로드맵>
     - 05월 17일(금) : 이스탄불HF EIP 접수 확정기한
     - 07월 19일(금) : 주요 클라이언트의 EIP 구현 마감기한
     - 10월 30일(수) : Ropsten Testnet HF
     - 12월 중 : Mainnet HF(=Istanbul HF)


□ 이스탄불 HF 

  ㅇ HF 시점 선정
    - Danno는 12월 4일 또는 11일로 선정하자고 했고, 이에 Tim은 앞으로 6주정도의 시간이 주어질거라고 첨언했다. Hudson은 12월 4일로 동의했음을 다시 언급하며 포크 블록넘버는 Gitter 채팅을 통해 정하자고 말했다.

    - Piper는 예기치못한 일로 인해 포크 일정을 늦출수 있고 그경우 4주정도 늦춰질거라고 말했다. Danno도 4주의 기간이 필요한 이유는 모든 클라리언트들이 포크블록넘버를 그들의 코드에 입력하고 모든 거래소와 노드운영자들은 코드를 받아서 설치해야하기 때문이라고 말하면서 일정이 늦춰진다면 최소 4주의 시간이 필요하다고 말했다. Hudson은 포크 시점을 12월 4일로 하고 유사시 연기시 포크시점을 1월 8일로 하자고 말했다.

  ㅇ EIP-2124 : 노드의 소프트웨어버전 식별 메커니즘
    - karalabe는 포크ID*가 지난 5월에 이더리움 클라이언트들이 사용 중인 노드(컴퓨터서버)의 소프트웨어 버전을 쉽게 식별할 수 있게 하는 메커니즘인 EIP-2124를 처음 제안했으나, 일반 클라이언트들은 대부분의 채굴자와 무관한 소외된 블록체인(non-majority chain)에 맞추기 위해 수기작업을 해야하는 어려움이 계속 존재하기때문에 다시 제안하는 바이다. 포크ID가 그런 어려움을 해소할수 있고, 이것은 작지만 결코 무시할 수 없는 변화다. 

    - James는 EIP-2124에 의한 변경은 하드포크가 필요없는 건 알지만 EIP 제안 및 실행과 같은 과정이 필요한지 물었고, karalabe는 그렇다고 말했고 Piper는 모든 사용자가 동의할 필요도 없고 네트워크에 영향을 끼치는 것이 아니기때문에 클라이언트는 원한다면 오늘이라도 실행할수 있다고 설명했다.

  ㅇ EIP중심 체제에 대하여
    - Hudson이 이스탄불HF이후에 있을 베를린HF이전에 있을 빙하기(채굴난이도상승)지연에 대한 예상을 물었고, karalabe, Piper, Martin은 빙하기 지연 건은 하나의 EIP로 하여 처리하면 된다고 말했다. 

    - 이에 논의의 무게중심은 'EIP중심체제의 포크가 적절한가'로 옮겨갔고 여러 개발자들의 의견이 이어졌다. Tim은 6개월이라는 기간을 우선 설정해놓고 그때까지 준비된 모든 EIP에 대해서 포크를 실행하자고 제안했다. 하지만 karalabe는 6개월간 한개 또는 두개의 EIP가 준비될 가능성이 있다면서 시간에 구애받지 않고 많은 EIP를 묶어서 6개월 간격이든 8개월 간격이든 포크를 해야한다고 반론했다. 이에 Pooja는 일년에 두번의 포크를 목표로 하되  EIP준비상황에 따라 포크시점을 정하는 하이브리드 방식을 제안했다. 

    - Martin은 빙하기 지연에 대한 EIP를 작성한 자원자가 있는지 물었고 Hancock이 자원하면서 차기 포크의 코디네이터가 되었다. 

    - Alex는 EIP중심체제 대하여 각 EIP책임자들이 그것에 대한 아이디어를 공유하는데 관심만 갖고 클라이언트 개발자들이 그것을 완료하는데 기대한다고 지적했다. 이에 Hudson은 본질적으로 중요한것은 우리가 EIP중심체제에서 더욱 동기부여할수 있는 방법을 찾는거라고 말하면서, EIP관련자들이 그것에 덜 관심갖게 된 이유는 더 많은 인적자원들이 있어서 이전보다 남들이 대신 해줄거라는 기대감이 더욱 커졌기 때문이라고 지적했다. 
   


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

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

# Raven Devs Meeting(25 Oct 2019) 


□ Analysis of the meeting by subject

  ㅇ Mailing list
    - Tron said the first mailing list is set up and if you apply for mailing service*, you can receive three types of mail(Updates, Dev, Alerts).
     * Mail application link : https://cdn.forms-content sg-form.com/8ec7a872-d599-11e9-ada2-7a44cc589a29
    - WuKong asked who would decide what to add in the mail, and Tron usually said devs would be to inform about APIs, 2nd tier solutions, etc..

  ㅇ Testnet status
    - Tron said devs will evaluate testnet for the features like restricted assets and messaging after the hackathon(end of October). If it goes well, then bug bounty, then activate the BIP9 date. Blondfrogs added that most issues have been resolved ans we are waiting of bug bounty feedback which we will announce after WCC(World Crypto Conference). Specifics will be outlined in an article later, he said.
     * BIP9 specifies how much support and how specific proposals are supported on the network for network maintenance and improvement. Normally, if more than 95% of the miners send support to the proposals, the proposed functions are locked in and then activated.

  ㅇ Ravencoin IPFS
    - Adam(Ravenland) launched multi-region IPFS* Hosting Solution(mypin.io) for Raven this week and said up to 250MB is now available for free. He said he will develop this for new features that will be on Raven mainnet in the future, and that IPFS is now hostable in Singapore, New York, Ottawa and Berlin.
     * IPFS is a P2P file system that implements distributed repositories as an integral part of the next-generation web (Web3.0) beyond the present relatively unstable web.
    - Adam said through mypin service that he would provide coin rewards or storage like Storj to those hosting IPFS nodes, predicting that demand will increase in the future, although it is still only about 1TB to host Ravencoin IPFS.

  ㅇ Raven mining hash status
    - The Raven nethash was recently around 10TH/s, and Blongfrogs said the figure has increased over the past two weeks and is very healthy. However, he speculated that the hash increase for two weeks may have been caused by the influx of new GPU miners or hardware(such as FPGAs).

  ㅇ Discussion on ASIC Resistance
    - Dan1666 said hardfork isn't a long-term plan for ASIC resistance, and PlayHard said
the timing is important, though it was carried out under consensus.
    - Traysi said, "There has been very good quality conversation happening in algo channel, and we hope to present a definite plan* soon."
     * Traysi is a dev who said before hardfork in October that there was already a long-term plan for ASIC resistance, and I, WuKong, am also participating in the algo channel with access authority from Traysi.

  ㅇ Ads through Raven wallet
    - Dan1666 said there was a movement on certain group(https://twitter.com/kawvertise) to send ads through Raven wallets*. In fact, the group claimed to be able to send ads to 5.6 million Raven addresses.
    - Bianca_NL said we're going to have more spam ads in the future and it's important
how we manage the wallets, and that maybe it's good to move them in the wallet to another section or tab so that they are no longer immediately visible
    - In response, other devs suggested creating a blacklist for spammers, and Blondfrogs even suggested that we mark them as assets sent to an address that has already received something set to hidden automatically


□ Personal Comments

  ㅇ Ravencoin Development Manual
    - Various opinions on the development and improvement of Ravencoin project were discussed once again through the meeting, thanks to the end of the war of ASIC resistance due to the fork in early October. Let's take a look at one by one with me.
    - First of all, it is about mailing list. As mentioned earlier, there will be three types of emails and contents. I have already received the mail which includes an overview of the Ravencoins and helpful links. It is an English mail, but I hope the mail subscribers will have the necessary information.
    - Second, it is about the status of testnet. Currently, restricted assets and messaging functions are being reviewed and revised on the testnet. BIP9 is used to verify support for testing these functions. As described earlier, BIP9 is about what proposals to get activated and how they are supported by the network supporters, and since Raven is also based on PoW, its miners can establish a consent expression for the block's header
information to see how much agreement has been made from the network participants.
    - Third, it is about InterPlanetary File System (IPFS). This conncets nodes in P2P way without a central server(Distributed), high-capacity files avoiding redundancy(Efficiently storable), and once uploaded files are recorded forever(Easily maintaining files). For Raven, IPFS is very important because it is used to issue metadata, messaging, and transaction metadata, and mypin.io mentioned in the meeting is a solution to better reflect the characteristics described earlier.
    - Fourth, spam-like ads on Raven wallets. Although it is not an important issue yet, spam advertising is a not-so-light problem that personally I have already experienced while holding some coins. It's a way for someone to send ads with a message on the transaction while sending an asset to a single Satoshi into a number of wallets, and I'm also offended to see a deposit containing spam ads in my wallet. Even though I had some assets deposited into my wallet. Given that the messaging function will be implemented in the future and many assets will be tokenized on Raven mainnet, it could be a bigger problem than other coin projects if not prepared.
    - I didn't explain all the issues discussed at this dev meeting, but I chose and explained four issues in my own way to improve your understanding of development, so please refer it to the Raven analysis and investment. In addition, like all coin projects, I want to show high respect to those who believe in and invest in Raven's potential despite this ever-changing crypocurrency market.

"Values come from long-term holding" -WuKong


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.



(한국어 버전)

□ 소재별 회의 내용

  ㅇ 메일링 서비스(Mailing list)
    - Tron은 첫번째 메일링 서비스가 출시되었고, 메일링 서비스 신청*을 하면 3종류(일반뉴스, 특이사항, 개발정도)의 메일을 받을수 있다고 말했다.
    * 메일신청링크 : https://cdn.forms-content.sg-form.com/8ec7a872-d599-11e9-ada2-7a44cc589a29
    - WuKong은 그 메일링 서비스에 들어갈 내용은 누가 정하는지 물었고, Tron은 보통 개발자들이 정할거라고 답했다.

  ㅇ 테스트넷 현황
    - Tron은 10월말 레이븐 해커톤 이후에 (제한자산, 메시징 등의 기능에 대한) 테스트넷에 대한 평가를 할거라고 말했고, Blondfrogs는 평가를 다 마친뒤 있을 버그바운티에 대한 피드백은 10월말 WCC(World Crypto Conference)이후에 공지될거라고 말했다. 그들은 이 모든게 잘 이행되면 BIP9*날짜를 활성화할것이라고 말하면서 세부사항은 글을 통해 알릴거라고 말했다.
     *(필자주)BIP9는 네트워크 유지관리 및 개선을 위해 특정제안이 네트워크에서 얼마나 지지받는지 그리고 어떻게 적용되는지에 대해 정한다. 통상적으로 95%이상의 채굴자가 해당제안에 지지의사를 보내면 제안된 기능은 락인되고 활성화된다.

  ㅇ 레이븐코인 IPFS
    - Adam은 레이븐랜드에서 레이븐을 위한 다지역 IPFS* 호스팅(Multi-region IPFS hosting solution)을 출시(mypin.io)하였고 현재 250MB까지는 무료로 사용가능하다고 말했다. 그는 향후 레이븐메인넷에 적용될 새로운 기능들을 위해 이것을 개발할것이며, 현재 IPFS는 싱가폴, 뉴욕, 오타와, 베를린에서 호스트가능하다고 말했다.
     *(필자주)IPFS는 상대적으로 불안정한 현재의 웹을 넘어선 차세대 웹(Web3.0)의 필수요소로, 분산 저장소를 구현한 P2P파일시스템이다. 
    - Adam은 mypin서비스를 통해 IPFS노드를 호스팅하는 이들에게 코인보상과 Storj와 같은 저장소를 제공할거라고 말하면서, 아직은 레이븐IPFS 호스팅하는데 1TB정도밖에 되지 않지만 향후 수요가 늘어날것이라고 예상하였다.

  ㅇ 레이븐 채굴해시 현황
    - 레이븐 넷해시는 최근에 10TH/s정도이며, Blongfrogs는 이 수치는 지난 2주간 증가하였으며 매우 건전한 수준이라고 말했다. 다만, 그는 2주간 해시증가에 대해서는 새로운 GPU채굴자들이 유입했거나 FPGA 등과 같은 특정 하드웨어가 만들어졌을거라고 추측하였다.

  ㅇ ASIC저항에 대한 논의
    - Dan1666은 하드포크는 ASIC저항에 대한 장기계획이 아니라고 말했고, PlayHard는 합의하에 진행하되 타이밍이 중요하다고 말했다.
   - 이에 traysi는 algo채널에서 높은 수준의 논의가 이어지고 있으며, 우리는 조만간 확실한 계획*을 선보이길 바란다고 말했다.
     *(필자주) traysi는 10월 하드포크 이전에 이미 ASIC저항을 위한 장기계획이 있다고 말한 개발자이며, 필자 역시 traysi로부터 접근권한을 받아 algo채널에 참여중이다.

  ㅇ 레이븐코인 지갑을 통한 광고
    - Dan1666은 특정집단(https://twitter.com/kawvertise)에서 레이븐코인지갑을 통해 각자가 원하는 광고를 전송하려는 움직임이 있다고 말했다. 실제로 그 집단은 560만개의 레이븐주소에 광고를 전송할수 있다고 주장하였다.
    - Bianca_NL은 우리는 스팸성 광고는 앞으로 더 많아질것이며 지갑을 얼마나 잘 관리하느냐가 중요하다고 말하면서, 아마도 그 스팸성 광고를 걸러내는 기능을 통해 다른 탭이나 섹션으로 옮기면 좋을것같다고 말했다.
    - 이에 대하여 개발자들은 스팸성광고를 보내는 자들을 위한 블랙리스트(Blacklist)를 만들자고 말했고, Blondfrogs는 한발 더 나아가 한번 숨기기를 한 스팸은 자동으로 숨길수 있도록 하는 아이디어를 제시하였다.


□ 개인 논평

  ㅇ 레이븐코인 개발 설명서
    - 10월 초 포크로 인한 ASIC저항전쟁이후 찾아온 종전덕분에 레이븐코인 프로젝트 개발과 개선에 대한 다양한 의견이 이번 회의를 통해 다시 한번 논의되었다. 필자와 함꼐 하나씩 살펴보자.
    - 첫번째로 메일링서비스에 관해서다. 앞서 언급된대로 3종류(일반뉴스, 특이사항, 개발정도)의 메일과 내용이 있을예정이다. 필자도 이미 메일을 받았고 해당 메일에는 레이븐코인에 대한 개요와 도움이 될만한 링크들이 명시되어있었다. 영어로 된 메일이지만 메일 구독자에게 꼭 필요한 정보가 담기길 바란다.
    - 두번째로 테스트넷 현황에 관해서다. 현재 레이븐코인 테스트넷에는 제한자산, 메시징 기능 등이 검토, 수정되고 있다. 이 기능들의 테스트에 대한 지지확인을 위해 BIP9이 사용된다. 앞서 설명된대로 BIP9는 특정제안이 네트워크에서 얼마나 지지받는지 그리고 어떻게 적용되는지에 대한 것으로, 레이븐 역시 작업증명방식의 합의규칙을 갖기에, 채굴자들은 해당 제안에 대한 지지의사(Signaling)를 블록의 헤더정보에 동의표시를 설정하는데, 이를 통해 네트워크 참여자들로부터 얼마나 합의가 이뤄졌는지 확인할수 있다.
    - 세번째로 IPFS(InterPlanetary File System)에 관해서다. 이는 중앙서버없이 P2P로 노드를 연결(분산화), 고용량 파일도 중복을 피하며(효율적 저장), 한번 업로드된 파일은 영원히 기록(파일유지관리 용이)되는 특징이 있다. 레이븐에게 있어 IPFS는 메타데이터, 메시징, 트랜잭션 메타데이터 발급에 사용되기 때문에 중요하며, 회의에서 언급된 mypin.io는 앞서 설명한 특성을 잘 반영하기 위한 솔루션이다.
    - 네번쨰로 레이븐지갑에서의 스팸성 광고다. 아직은 중요한 문제가 아니지만 개인적으로 스팸성 광고는 이미 특정 코인을 보유시 경험한 가볍지 않은 문제다. 누군가가 수많은 코인지갑들에 자산을 1사토시에 전송하면서 그 트랜잭션에 메시지를 담은 광고를 전송하는 방식인데, 필자 역시 입출금 알림을 설정한 지갑에 가끔 스팸성 광고를 담은 입금건을 보면 불쾌하다. 그게 설령 내 지갑에 자산이 입금되는 것임에도 말이다. 레이븐은 향후 메시징 기능이 구현될거고 수많은 유무형자산이 올려질것이기에 미리 대비하지 않으면 다른 코인 프로젝트보다 더 큰 문제가 될수도 있다.
    - 회의에서 논의된 모든 안건에 대한 설명을 하지 않았지만 개발 이해도를 높이기 위해 필자 나름대로 4가지 안건을 선택하여 설명해봤으니 레이븐 분석과 투자에 참고하기 바란다. 아울러, 모든 코인프로젝트도 마찬가지겠지만 끊임없이 요동치는 시황에도 불구하고 레이븐의 잠재력을 믿고 투자하는 분들에게 이 글을 빌어 경의를 표하는 바이다.

"가치는 장기홀딩에서 나온다"  -코인논객오공



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

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

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