# 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저항방법이 나오길 바라며, 우리 커뮤니티도 그 과정을 묵묵히 지지해주기를 바란다.
법적 고지 : 본 게시글은, 투자를 위한 정보제공을 목적으로 작성되었기에 투자결정은 신중을 기하여 주시기 바라며, 참고자료를 토대로 본인 판단하에 내용을 추가, 편집 등 작성되었기에 본인의 허락없이 복사, 배포, 편집 등을 할 수 없습니다.
