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

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

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

#74 Devs Meeting Review(1 Nov 2019)

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

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

□ Istanbul HF update

  ㅇ Istanbul HF block number
    - Hudson said block number for Istanbul was born; 9,069,000, asking when clients are releasing an update with the [Istanbul] block number attached.
In response, Tim replied by mid-November, within two weeks.
- Hudson also said the Ethereum Foundation and/or Ethereum Cat Herders are publishing a blog on the block number and what software to upgrade when host clients update their download links.

□ Finally accepted EIPs in Istanbul HF

    1) EIP-152 (former EIP-2024) : Introducing a pre-compiled cotracts for EVM that implements a new encryption hashing algorithm called BLAKE2b.
    2) EIP-1108 : Proposal for reducing gas cost of alt_bn128 pre-compile. Improving personal information protection and scalability by reevaluating expensive elliptical curve calculation pre-comfiles.
    3) EIP-1344 : Specifying chain ID(a means to prevent replay of transactions between different chains), adding opcodes to access the chain ID to check the validity of signatures, and preventing other interchain replay attacks.
    4) EIP-1884: Maximizing block gas limit and stabilizing processing time by balancing gas consumption and resource consumption.
    5) EIP-2028 : Reducing gas cost of Calldata(where transaction data is stored when transaction is requested on the chain). Reducing Calladata costs can create potentially larger blocks, which can increase network latency, but can also have incidental effects of increased network security and scalability due to mathematical modeling and empirical estimation.
    6) EIP-2200(EIP-1283 + EIP-1706): Changing the total gas metering to reduce new usability for smart contract storage and excessive gas consumption when most methods of operation are not in place. In addition, SSTORE is not allowed if gas cost is lower than call stipend.

□ Berlin HF

  ㅇ Ice Age (Ice Age)
    - Tim said we said that the Ice Age would start kicking in next summer, please correct me if I'm wrong. We probably want an EIP in Berlin that kicks back the Ice Age.
Hudson noted that James Hancock decided to write the EIP with no need to rush.

  ㅇTentatively Accepted EIPs in Berlin HF
     1) EIP-663: Currently, SWAP and DUP commands are limited to the depth of 16 on the stack, but and corresponding SWAPn and DUPn are allowed access to all depths of 1024 items thanks to this EIP.
     2) EIP-1057 : It is called ProgPoW and is modified to make the most of commercial GPU resources in order to reduce ASIC's improved efficiency.
     3) EIP-1380: Reducing gas cost for self-calls, and reducing gas cost for call instructions when running a new instance of the currently loaded contracts.
     4) EIP-1702: For generalized account version management, enabling multiple versions of EVM to execute in the same block to facilitate HF while maintaining the correct function of the existing account.
     5) EIP-1962: Proposal to the definition and combination of elliptical arithmetic and runtime, an extension to EIP-1829 and lower working costs than the STATICCAL opcode in EIP-1109.
     6) EIP-1985: Applying the appropriate limit range for EVM parameters such as gas limit and block number. Explicit scope makes it easy to implement compatible clients.
     7) EIP-2045:improving the speed without introducing a separate subroutine and without changing the method of jump operation by reducing gas cost of computational opcode gas cost to increase Ethereum transaction volume(scalability).
     8) EIP-2046: Making file usage more efficient by reducing the gas of static calls to pre-com files.
     9) 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.

□ Discussing the process and schedule

  ㅇDiscusson on EIPs and forks
    - Alex said that for every EIP change, record a decision in the meeting notes so EIP editors can extract on the meeting notes, for standing PRs.
    - James said that all EIPs, except for the ice age that needs to be updated every month deciding whether to go or to postpone. He also said that We want to avoid one fork per EIP, as well as waiting significant time to include several EIPs, as both limit implementations, testing, etc.In response, Hudson added that for most EIPs, we can decide, implement, and do tests for an EIP within a 3-4 week period as well as the champion of an EIP and the coordinator for testing.

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은 이스탄불HF 블록넘버가 9,069,000으로 정해졌다고 말하면서, 언제 클라이언트들이 블록넘버가 첨부된 업데이트 버전을 출시하는지 물었다.
이에 Tim은 2주이내인 11월 중순까지라고 답했다.
    - 또한 Hudson은 이더리움재단과 이더리움 캣허더가 블로그를 통해 블록넘버와 클라이언트의 업데이트 버전을 게시할거라고 말했다.

  ㅇ 이스탄불HF 확정승인 EIP
     1) EIP-152(前 EIP-2024) : BLAKE2b라는 새로운 암호화 해싱 알고리듬을 구현하는 사전컴파일 컨트렉트를 EVM에 도입.
     2) EIP-1108 : alt_bn128 프리컴파일 가스비 절감제안. 값비싼 타원곡선산술 사전컴파일을 재평가하여 개인정보보호와 확장성을 개선.
     3) EIP-1344 : 컴파일링시 체인ID(서로 다른 체인간 트랜잭션 재생을 방지하는 수단)를 지정하고 opcode를 추가하여 그 체인ID에 접근하여 서명의 유효성을 검사하며, 다른 체인간 리플레이 어택 등을 방지.
     4) EIP-1884 : 가스소비와 자원소비 간 균형을 맟추어 블록가스제한을 극대화하고 처리시간을 안정화.
     5) EIP-2028 : Calldata(이더리움 상에서 트랜잭션 요청시 전송 데이터가 저장되는 곳)의 가스비를 현행보다 감소. Calladata비용이 절감되면 잠재적으로 더 큰 블록이 생겨 네트워크 지연이 증가하지만, 수학적 모델링과 경험적 추정에 의해 네트워크 보안이 강해지고 확장성이 증가되는 부수적인 효과가 있을수도 있음.
     6) EIP-2200(EIP-1283 + EIP-1706) : 총 가스 계량기(Net gas metering)를 변경하여 스마트컨트렉트 저장소를 위한 새로운 활용가능성과 대부분의 작동방식이 맞지 않을때 발생하는 과도한 가스비를 감소. 또한, 가스비가 집행비(Call stipend)보다 낮은경우 SSTORE사용을 불허함.

□ 베를린HF

  ㅇ 빙하기(Ice Age)
    - Tim은 일전에 우리는 내년 여름에 빙하기가 시작될거라고 말했는데, 아마도 베를릴HF때 빙하기를 중단하는 EIP가 필요할지도 모른다고 말했다.
이에 Hudson은 James가 그 EIP를 작성하기로 했고 크게 서두를 필요가 없다고 언급했다.

  ㅇ 잠정승인 EIP
     1) EIP-663 : 현재 SWAP과 DUP명령어는 스택상 16의 깊이로 한정되어있는데, 이들과 대응되는 SWAPn과 DUPn을 1024개의 아이템의 모든 깊이까지 접근을 허용한다.
     2) EIP-1057 : ProgPoW로 불리며, ASIC의 향상된 효율성을 반감시키위하여, 상용GPU자원을 최대한 활용되도록 수정.
     3) EIP-1380 : 자기호출에 대한 가스비 절감으로, 현재 로드된 컨트렉트의 새 인스턴스를 실행시 호출지시에 대한 가스비를 절감.
     4) EIP-1702 : 일반화된 계정버전 관리를 위한 것으로, EVM의 여러버전을 동일한 블록에서 실행할 수있게하여 기존 계정의 정확한 기능을 유지하면서도 HF를 용이하게 함.
     5) EIP-1962 : 타원 산술 및 런타임 정의와 결합에 대한 개선안으로, EIP-1829에 대한 확장안이며 EIP-1109에서의 STATICCAL opcode보다 작업비용이 더 저렴.
     6) EIP-1985 : 가스제한, 블록넘버 등 EVM 매개변수들에 대한 적정 한계범위를 적용한다. 명시적인 범위를 적용하면 호환가능한 클라이언트를 구현하는데 용이함.
     7) EIP-2045 : 이더리움 거래량(확장성)을 높이기 위하여 Computational opcode의 가스비를 줄여서 별도의 서브루틴 도입없이 또 점프작동방식을 변경없이 속도를 향상함.
     8) EIP-2046 : 프리컴파일에 대한 정적호출의 가스비를 줄임으로서, 파일사용이 보다 효율적.
     9) EIP-1559 : 현재의 비효율적이고 불필요한 가스비가 드는 방식을 벗어나, 네트워크 수요에 따라 기본 네트워크 요금을 조정하고 비용 효율성을 높이며 가스비지불에 있어 사용자 편의성을 높임.

□ 과정 및 일정 논의

  ㅇ EIP와 포크
    - Alex는 모든 EIP변경에 대해 회의록에 결정사항을 기록하여 EIP작성가 코드변경을 실행할 수 있도록 하게 하자고 말했다.
    - James는 업데이트가 필요한 빙하기를 제외한 모든 EIP는 특정실행시점을 정하기보다 매월 실행할지 지연할지 결정할수 있다고 말했고, 또한 EIP당 하나의 포크를 지양하고 여러 EIP에 대한 테스트, 구현 등을 위해 상당한 시간을 갖길 선호한다고 밝혔다. 이에 Hudson은 대부분의 EIP의 경우, 우리는 3-4주내에 테스트, 구현을 할수 있고, 누가 테스트할지 담당할지 정할수 있다고 첨언했다.

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

[Bitcoin] 인류사회, 불확실성, 그리고 비트코인(광고주의)

□ 인류사회를 지배해온 것들   ㅇ투쟁의 역사와 자연의 섭리     - "지금까지의 모든 사회의 역사는 계급투쟁의 역사다". 이 문구는 공산주의 창시자인 칼 마르크스와 프리드리히 엥겔스가 「공산당 선언」에 나온 문구로 인류 역사는 경...