[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.

  ㅇEIP-1803
    - 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 재실행, 외부인에게 프로세스를 명확하게 하는 방법 등 모든 측면을 다룰거라고 말했다. 



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