[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관련자들이 그것에 덜 관심갖게 된 이유는 더 많은 인적자원들이 있어서 이전보다 남들이 대신 해줄거라는 기대감이 더욱 커졌기 때문이라고 지적했다. 

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

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

# Ravencoin 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가지 안건을 선택하여 설명해봤으니 레이븐 분석과 투자에 참고하기 바란다. 아울러, 모든 코인프로젝트도 마찬가지겠지만 끊임없이 요동치는 시황에도 불구하고 레이븐의 잠재력을 믿고 투자하는 분들에게 이 글을 빌어 경의를 표하는 바이다.

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

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

[News] Libra의 위협에 미국 중앙은행 'FedCoin' 발행 재고 // Threatened by Libra, US Central Bankers Reconsider a ‘FedCoin’ v1.0

Threatened by Libra, US Central Bankers Reconsider a ‘FedCoin’Libra의 위협에 미국 중앙은행 FedCoin 발행 재고

< https://beincrypto.com/threatened-by-libra-us-central-bankers-reconsider-a-fedcoin >

□ 기사 내용

Facebook’s proposed digital currency, Libra, appears to have forced the US Federal Reserve to reconsider the idea of issuing its own purely digital means of payment. The issue is expected to be a hot topic at meetings of the International Monetary Fund and World Bank this week.
Facebook이 제안한 디지털 통화인 Libra는 미국 연방준비제도이사회(FRB)가 디지털 결제 수단을 발행하는 방안을 재고하도록 강요한 것으로 보인다. 이번 주 국제통화기금(IMF)과 세계은행(World Bank) 회의에서 이 문제가 화두가 될 것으로 보인다.

According to a report in Politico, numerous federal bankers have expressed a sense of urgency in exploring the idea of a so-called “FedCoin”.
Politico의 한 보고서에 따르면, 수많은 연방 은행가들이 소위 "FedCoin"의 아이디어를 탐구하는 데 있어 긴박감을 표현했다고 한다.

The issue appears to have largely been dismissed by the Federal Reserve last year. In May, a governor on the central bank’s board, Lael Brainard, spoke openly against central bank-issued digital currencies, citing digital security issues as causes for concern.
이 문제는 지난해 연방준비제도이사회(FRB)에 의해 거절된 것으로 보인다. 지난 5월 Lael Brainard 중앙은행 이사장은 디지털 보안 문제를 우려하며 중앙은행이 발행하는 디지털 통화에 대해 공개적으로 반대 입장을 밝혔다.

However, with Facebook going public with its financial ambitions this June, as BeInCrypto reported, the issue has been forced into the minds of central bankers and lawmakers around the world.
그러나, BeInCrypto의 보도처럼 Facebook이 올 6월에 Libra의 재정적 야망을 공개하면서, 이 문제는 전 세계의 중앙 은행가들과 국회의원들을 동요시키고 있다.

Libra of Facebook
Concern Over Libra
Concerned by the Libra project, Rep. French Hill (R-Ark) joined fellow members of Congress to ask Federal Chair Jerome Powell to consider the creation of a central bank-issued digital currency. He argued for a more concerted effort from the Federal Reserve to analyze the implications of such a move and potentially make preparations for it.
Facebook의 Libra
Libra에 대한 우려
Libra 프로젝트와 관련하여, French Hill 공화당 의원은 의회 동료 의원들과 함께 Jerome Powell 연방 의장에게 중앙은행이 발행하는 디지털 화폐 발행을 고려할 것을 요청했다. 그는 연방준비제도이사회(FRB)가 Libra와 같은 움직임의 의미를 분석하고 잠재적으로 그에 대한 준비를 하기 위해 더욱 힘을 모아야 한다고 주장했다.

Rep. Bill Foster (D-Ill) joined Hill in raising concerns to Powell. He questioned whether it was right for an entity outside of government to be responsible for the monetary system.
Bill Foster 공화당 의원은 Hill 차관보와 함께 Powell 장관에게 우려를 제기했다. 그는 정부 밖의 기업이 통화제도에 대해 책임을 지는 것이 옳은지에 대해 의문을 제기했다.

“A consumer payments system is a natural monopoly… The question arises — shouldn’t it be the U.S. taxpayer and the U.S. government that does it rather than any private firm?”
"소비자 결제시스템은 자연독점의 문제로, 이쯤되면 그 시스템을 구축하는 일이, 어떤 민간 기업보다 미국 납세자와 미국 정부여야 하는 것이 아닌가라는 의문이 생긴다."

Meanwhile, the president of the Philadelphia Department of the Federal Reserve said that at this point, the creation of a Federal Reserve digital currency was a foregone conclusion. He added that it was important for the bank to hasten its progress towards understanding and implementing such a system.
한편, 연방준비제도이사회(FRB) 필라델피아 지사 총재는 현시점에서 연방준비제도이사회(FRB)의 디지털 화폐의 발행은 기정사실이라고 말했다. 그는 은행이 그러한 제도를 이해하고 시행하는 방향으로 나아가는 것이 중요하다고 덧붙였다.

Facebook of Libra
Clearly Threatened by Facebook
Facebook’s Libra project has clearly rattled the US government. Although President Donald Trump dismissed the idea that the social media company’s proposed currency would be a threat to the dollar, his Treasury Secretary, Steven Mnuchin, described it as a potential national security issue earlier this year. More recently, two senators put pressure on key members of the consortium of companies behind the Libra project. As BeInCrypto has previously reported, this appears to have resulted in the likes of Visa, MasterCard and other big names withdrawing their support.
Libra의 Facebook
Facebook에 의해 명백히 위협받고 있다
Facebook의 Libra는 분명히 미국 정부를 뒤흔들어 놓았다. Donald Trump 대통령이 Libra가 달러에 위협이 될 것이라는 생각을 일축했지만 Steven Mnuchin 재무장관은 올해 초 이를 잠재적 국가 안보 이슈로 표현했다. 더 최근에는 두 명의 상원의원이 Libra 프로젝트 배후에 있는 기업 컨소시엄의 핵심 멤버들에게 압력을 가했다. 이전에 BeInCrypto가 보고한 바와 같이, 이것은 비자, 마스터카드 그리고 다른 거물들이 그들의 지지를 철회하는 결과를
가져온 것으로 보인다.

Given its vast existing user base, the threat posed by Facebook’s Libra to the existing financial status quo appears more pronounced than that of Bitcoin and other cryptocurrencies. At a recent Senate testimony, former chair of the FDIC, Shelia Bair, summed up the growing sentiment amongst US lawmakers.
Facebook의 Libra가 기존의 수많은 사용자 기반을 감안할 때, Bitcoin이나 다른 암호화폐보다 현재의 재정 상태에 대한 위협이 더 뚜렷하게 나타난다. 최근 상원 증언에서 전 FDIC 의장인 Shelia Bair는 미국 국회의원들간의 공감대를 형성했다.

“If the Fed does not stay ahead of this rapidly maturing technology, I fear private sector efforts to eclipse fiat monetary systems will get ahead of them, with potential disruptions to our banking system and in a worst case scenario, loss of control of our own currency.”
그는 "빠른 속도로 성숙하는 이 기술에 미 연준이 앞서가지 않는다면, 나는 우리 은행 시스템에 잠재적인 차질이 생기고 최악의 경우 우리 통화에 대한 통제력을 상실하는 등 금융 시스템을 일식하려는 민간 부문의 노력이 그들을 앞지르지 않을까 우려한다"고 말했다.

□ 개인 논평

  ㅇ 내 이럴줄 알았다
    - 필자가 이 기사를 보자마자 이럴줄 알았다고 생각했다. 기사의 내용처럼 중앙은행 디지털통화(Central Bank Digital Currency, CBDC)에 대하여 지난해 연방준비제도이사회(FRB)는 거절하였고 지난 5월에는 중앙은행 이사장은 디지털 보안 문제를 우려하며 반대하였다.
    - 그랬던 그들이 Facebook의 Libra 출시를 보고 생각이 바뀐듯 하다. 그새 그간 우려했던 디지털 보안 문제가 해소된건가, 아니면 뭔가 획기적인 기술의 진보가 있었던건가. 얼핏 생각하면 그런 태세전환이 결코 간단치 않다는 걸 알게된다. 그들은 어떤 셈법으로 자신들의 결정을 번복하면서까지 미 연준발 코인(이하 'FedCoin') 발행을 긍정적으로 생각하는 것을 넘어서서 기정사실로 인정하는 걸까.

  ㅇ 미 연준의 빠른 태세전환
    - 그러면 왜 미 연준과 중앙은행은 디지털 통화에 대한 태세를 전환한걸까. 첫째로, Libra 덕분에 '기회'를 봤을것이다. 지난번 분석한 기사(여기 클릭)을 보면 Facebook은 20억명이 넘는 사용자를 보유할정도로 유명하고, Libra로 인해 경제력이 약한 국가들을 잠식할정도로 강력하고, 정부나 당국이 아닌 거대 민간기업이 돈을 찍어낼 뜻을 가질정도로 상징적이며, 디지털 통화의 주도권을 선점할정도로 선도적이다. 또한, Libra가 단순한 디지털 통화를 넘어서 LIT토큰을 활용한 분산금융(Decentralized Finance)까지 손을 뻗고 있다. 이런 개념들이 전에 없던 완전 새로운 것이라기보다 이전에 있던 것을 유의미한 수준으로 탈바꿈하는 것이기에 더욱 혁신적이다. 즉, 리스크를 최소화하면서 이익을 극대화할수 있는 '새로운 분야의 개척'인것이다. 정부와 당국은 일부 기업들이 탈퇴했다고 하지만 Libra와 협력기업들을 보고 군침을 흘렸을 것이다. 그들에게 디지털통화의 영역은 생존의 문제이자 또다른 번영의 문제이다. 따라서, 그런 기회를 절대 놓치지 않을것이다. 둘째로, 중국의 디지털 통화 전자화폐(Digital Currency e-Payment)(이하 '디지털 위안') 때문에 '위기'를 느꼈을것이다. 이전 분석기사(여기 클릭)에서 언급했듯이 중국 당국의 관계자는 디지털위안이 결코 Libra의 카피본이 아니라고 밝혔다. 실제로 디지털 위안은 Libra에는 없는 NFC결제 방식 등 기능을 탑재하면서 더 우세하다는 뉘앙스를 풍겼다. 그런데 미국 측이 위기를 느끼는 대목은 그러한 기능때문만은 아니다. 페트로 달러(필자주: 석유에 대한 결제통화인 미달러의 위상을 지칭)로 대변되는 미국 달러의 패권의 아성을 현재의 중국 위안이 넘기 힘들었지만, 새로운 판에서는 승산을 장담할수 없다. 따라서 새로운 판인 디지털 통화 영역에서 어떤 방향으로 얼마나 빨리 선점하고 선도하느냐에 따라 국가 경제력은 물론 그 국가의 위상은 매우 높아질 것이다. 이런 모든 시사점을 미국이 놓칠리 없고 중국 역시 마찬가지다.

  ㅇ 관전 포인트
    - 필자가 분석한 사유가 정답이 아닐수도 있고, 맞는다해도 이게 전부는 아닐것이다. 중요한 점은 암호화폐는 물론 디지털 통화로의 진입과 경쟁은 앞으로 더욱 치열해질것이고, 그것의 주체는 정부가 될수도 있고, 기업이 될수도 있고, 심지어 영향력있는 개인까지 넓혀질것이다. 그런 과정에서 블록체인과 암호화폐의 가능성인 '권한의 분산화' '가치의 바다'가 어느정도까지 실현될지 두고두고 지켜봐야할것이다.

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

[Poem] 세력과 개미의 싸움(원작 : 안도현의 '칼과 풀잎의 싸움') v1.1

<세력과 개미의 싸움>
 - 코인논객시인오공
< 다윗과 골리앗 (https://prayerhub.org) >

세력과 개미의 싸움이었다
세력이 버티자 큰손은 개미를 난도질했고
세력은 결국 시황에 등을 돌렸다
슬픈 일이지만 슬퍼할 필요는 없다
세력이 개미를 이긴게 아니다
세력은 머쓱해지겠다
세력은 이제 해야 할 일이 없다
세력은 개미의 '존버'를 보지 못했다
개미가 세력을 이긴 것이다

원작 : 안도현

칼과 풀잎의 싸움이었다
풀잎이 버티자 칼은 풀잎을 난도질했고
풀잎은 결국 스스로 목을 꺾었다
슬픈 일이지만 슬퍼할 필요는 없다
칼이 풀잎을 이긴게 아니다
칼은 머쓱해지겠다
칼은 이제 해야 할 일이 없다
칼은 풀잎의 '뿌리'를 보지 못했다
풀잎이 칼을 이긴 것이다

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

# Ravencoin Devs Meeting(11 Oct 2019) 

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

□ Analysis of the meeting by subject

  ㅇ Today's devs meeting agendas
   < Current Business >
    @ Restricted Assets Fork
     - Code is on Testnet
     - Binaries ready for Mainnet download when?
    @ Dividends
     - Maldon waiting for Blond Frogs to do a PR
   < Updates >
     - Tron : "I'll look at setting up a mailing list.(After Oct 1)"
     - qt for restricted assets
     - Ravencoin hackathon in vegas at the end of the month

  ㅇ New format for Devs meeting
    - At the beginning of each meeting, a format was established from this meeting to guide decisions made about the previous meeting and to introduce agendas for the upcoming meeting. Thanks to that, personally I feel that the efficiency and concentration of the meeting have a lot improved.

  ㅇ Open-source ASICs
    - From the beginning of the meeting, Wukong(It's me) has commented on the open source ASICs mentioned in the previous meeting by Tron Black ('Tron' from here), and has made the following comments: 'Open source ASICs could be one of the long term plans to resist ASICs but it needs community consensus and good stretagies including sufficient benchmarks. Although we created a new mining algorithm(x16r), to prevent immediate dominance by mining pools like ASIC mining, it doesn't mean that GPUs is the only solution and we shouldn't use ASICs to resist ASICs. In a way, new types of ASICs against ASICs would be worth trying and I believe one of the new types is open sourcing ASICs. More discussion is a must though'.
    - Tron also said that open-source ASICs is one option and it's an interesting idea, but it means that "we" (the community) need the expertise to be make one that's competitive. He also added that the upgrade(aka hard-fork) went well.  A butt-clenching 29 minutes for the first block, but after that - smooth sailing. But it was very disruptive to the roadmap development for months.
    - Someone_2 said that he wonders that we have secret asics creeping in but he feel feature implementation should be a higher priority currently.
    - Traysi said that the next fork for anti-ASICs needs to be done much quicker and he'd like to see a timeline proposed and work begun as soon as possible on a third algo. He thought that work doesn't have to stop on other RVN features because different people are involved in different parts of this work.

  ㅇ Raven Explorer translation into Korean
    - (As a dev who is thrilled with the Ravencoin Asia meetup) he's about to start translating Raven Explorer into Korean. For that, some devs were seeking for Bradar of the Ravencoin Korean community.

  ㅇ Upgrade(Fork) for features* Plan
    * This refers to a hard fork for applying features such as restricted assets and messaging to the mainnet, and is called a network upgrade because it is not intended for branching.
    - Restricted assets, messaging, etc are currently on testnet. After Raven Hackathon where some devs attend completed and bug bouty is completed, the upgrade is scheduled for early November. 

  ㅇ Transaction fees on Dividends/Rewards
    - KAWAR asked what the transaction costs will be of paying dividends to thousands of tokenholders. He also thought that if we can keep the transaction costs low then token holders could be paid more frequently whilst owning smaller fractions of an asset, adding that when RVN becomes too valuable, it would limit use cases and adoption.
    - Tron responded to the question, saying fees will be optimized with Rewards, but not eliminated.

  ㅇ Mailing list
    - Tron said he started working on the mailing list and it can be on several different sites: One for alerts(emergencies or upgrades), one for general info(frequent e-mails), and one for devs(tools, etc.).

  ㅇ Next anti-ASIC plan
    - Tron said that if we're going to go through this again, it needs to be a serious - no ASIC algo like CNv4, RandomX, etc. He also mentioned that one important consideration is that the tZero wallet and the RVN Wallet(mobile) need to be able to do in reasonable time for block verification. As for him, the x22r(with ASIC hard algo guaranteed in slots 1-20) is my preference at the moment, but could be tricky for mobile.
    - It's not decided yet, but there may be an anti-ASIC upgrade at certain times(next January for example).

□ Personal Comments

  ㅇ Anti-ASIC upgrade and Features upgrade
    -  It may seem boring to someone who is not familiar with it, but we need to briefly diagnose the anti-ASIC. Thanks to the fork on October 1, we earned at least three months to face another ASIC invasion. In this period, we must carry out two things carefully. First of all, there's a whole range of features that I've been putting off for a while. It shall be tested on testnet and implemented on the mainnet. As mentioned in the meeting, restricted assets and messaging are on testnet and plans to be applied to mainnet in early November. And then features such as dividends/rewards will be implemented on mainnet. So far, if Raven has played a preliminary match based on its listing in exchanges and growth of its community, it's time to play a main game based on features on mainnet. So I'm personally even more worried and looking forward to the future of Raven. Second, planning and implementation of ASIC resistance is another one. ASIC doesn't wait for us. ASIC mining sometimes secretly and aggressively damages the soul of projects on PoW. we've just earned at least three months and that's it! Rather, more sustainable ASIC resistance planning should begin from now on. If we think it's impossible to get out of control of ASIC, we seriously consider the method of gradually introducing ASIC in it, as long as certain mining groups do not monopolize hash power as PlanB. Because I personally think that 'Decentralization' is just a means to achieving a vision and not an end itself.
    - In any case, until the next anti-ASIC fork is in place, we can enjoy the promotion of development, community growth, and clarity of STO regulations. To enjoy more, we need to study and analyze our promising project, "Ravencoin". KAAWWW~

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.

(한국어 버전) 

□ 소재별 회의 내용

  ㅇ 회의 안건 
   < 현 안 >
    @ 제한자산(Restricted Assets) 등을 포함한 업그레이드
     - 테스트넷에서의 코딩중
     - 메인넷을 위한 Binaries 준비
    @ 배당(Dividends)
     - Maldon은 Blond Frogs이 PR(코드수정제안)하길 기다리는중
   < 업데이트 >
     - Tron의 메일링 서비스 계획
     - 제한자산(Restricted Assets)을 위한 Qt
     - 레이븐 해커톤 in 라스베가스

  ㅇ 회의진행포맷(New format for Devs meeting)
  - 매 회의 시작 이전에, 지난 회의에 대한 결정사항을 안내하고 차기 회의에 대한 안건을 소개하는 포맷이 이번회의부터 정착되었다. 그 덕분에 (회의에 참석한 필자 역시 확 느낄정도로) 회의의 효율성집중도가 높아졌다

  ㅇ 오픈소스 ASIC(Open sourcing ASICs)
    - 필자는 회의초반부터 트론블랙(이하 '트론')이 지난 회의때 언급한 오픈소스ASIC에 대한 의견을 냈고, 다음과 같은 의견을 냈다. '이 방식은 ASIC저항의 지속가능한 장기계획들 중 하나가 될수 있으나 커뮤니티의 합의와 충분한 벤치마킹을 포함한 좋은 전략이 필요하다. 우리는 ASIC과 같은 막강한 영향력에 의해 지배당하지 않기 위하여 x16r이라는 새로운 알고리듬을 만들었다. 허나 그말은 GPU가 그에 대한 유일한 해결책이라기보단 새로운 ASIC방식이 해결책이 될수도 있으며, 그 해결책들 중 하나는 오픈소스 ASIC이 될수도 있다고 나는 생각한다'라고 말했다.
    - 트론 역시 오픈소스 ASIC이 하나의 선택지라고 말했고, 그것이 경쟁력을 갖기 위해서는 전문가가 필요하다고 말했다. 다만, 포크이후 첫블록이 생성되기까지 29분이 소요된 점과, 이번 포크가 로드맵을 이행하는데 걸림돌이 된 점이 사실이라고 첨언하였다.
    - Someone_2는 ASIC채굴이 남모르게 진행되고 있는지는 모르겠지만, 현재는 기능구현이 더 중요하다고 말했다.
    - Traysi는 차기 (ASIC저항) 포크는 좀 더 빨리 완료되어야 하며, 시기와 작업을 가능한 빨리 해야한다고 말했다. 그리고, 각자 다른 사람들이 각기 다른 분야를 담당하고 있기때문에, 기능구현 작업을 멈출 필요는 없다고 첨언하였다.

  ㅇ 레이븐 익스플로러 한국어 번역
    - (레이븐코인 아시아 밋업에 감격한 개발자가로) 레이븐 익스플로러 한국어 번역 작업을 시작하려고 하며, 그것을 위하여, 레이븐코인 한국 커뮤니티의 Bradar님을 찾았다.

  ㅇ 기능 업그레이드(포크)* 계획
   *제한자산, 메시징 등의 기능을 메인넷에 적용하기 위한 하드포크를 의미하며, 분기를 목적으로 하지 않으므로 네트워크 업그레이드라고 불림 
    - 제한자산(Restricted assets), 메시징(Messaging) 등의 기능이 현재 테스트넷에서 테스트중이며, 일부 개발자들이 참여하는 레이븐 해커톤(10월말)이 끝나고 기능 업그레이드이전의 버그 바운티가 잘 완료되면 11월 초에 기능 업그레이드가 있을 예정이다.

  ㅇ 배당시 트랜잭션 비용
    - KAwAR은 토큰홀더들에게 배당할때 트랜잭션비용이 저렴하면 토큰홀더들이 자투리 자산을 활용하여 더 자주 배당받을수 있다고 말했다. 그러면서 그는 만약에 레이븐이 비싸질것을 대비하여 트랜잭션 비용을 어느정도로 정해야할지 물었다.
    - 트론은 그 질문에 대하여, 트랜잭션 비용은 보상과 함께 최적화될거라고 말했다.

  ㅇ 메일링 서비스(Mailing list)
    - 트론은 메일링 서비스 작업에 착수하였고, 일반뉴스, 특이사항, 개발정도 등 3가지 리스트를 구상중이라고 말했다.

  ㅇ 차기 ASIC저항 계획(Next anti-ASIC plan)
    - 트론은 ASIC저항계획을 다시 이행한다면, 그땐 좀 더 진지해야 한다며 알고리듬 변경은 지양하고 CNv4, RandomX와 같은 새로운 방식이 될수도 있다고 말했다. 그리고 중요한 점은, 어떤 포크를 하던지 티제로 지갑이나 레이븐 모바일 지갑에서 블록검증이 잘 되어야한다고 첨언하였다. 또한 현재로서는 x22r이 최선이지만 모바일 지갑 관점에서 보면 애매하다고 언급하였다.
    - 아직 정해지지 않았지만 특정시기(내년 1월이 후보)에 ASIC저항 업그레이드가 있을수도 있다고 일부 개발자들이 언급하였다.

□ 개인 논평

  ㅇ ASIC저항 업그레이드와 기능 업그레이드 
    - 잘 모르는 사람이 보면 지긋지긋하게 보일지도 모르겠지만, ASIC저항을 위한 포크를 간단히 진단해볼 필요가 있다. 10월 1일 포크덕분에 또다른 ASIC진입까지 최소 3개월의 시간을 벌었다. 몇 주간 개발자와 커뮤니티를 괴롭히던 이슈로부터 자유로워진 이 기간동안, 우리는 2가지를 빈틈없이 이행해야 한다. 첫째로, 잠시 미뤄뒀던 다양한 기능들을 테스트하고 메인넷에 구현해야한다. 이번 회의에서 언급된것처럼, 제한자산과 메시징이 테스트넷에서 테스트중이고 11월 초에 메인넷에 적용시키는 것을 계획하고 있다. 그리고 이어서 배당과 같은 기능도 메인넷에서 구현될것이다. 여태까지 레이븐이 거래소에서의 상장, 커뮤니티의 성장을 토대로 한 예선전을 치뤘다면, 이제부터는 그 가능성을 메인넷을 토대로 한 본게임을 치룰 차례이다. 그래서 더더욱 레이븐의 미래가 걱정되면서도 기대가 된다. 둘째로, 또다른 ASIC저항 계획수립과 이행이다. ASIC은 우리를 기다려주지 않는다. ASIC채굴은 떄로는 은밀하게 때로는 공격적으로 작업증명방식(PoW)의 프로젝트의 영혼을 잠식한다. 적어도 3개월의 시간을 벌었다한들 딱 그뿐이다! 오히려 그 기간동안 지금부터 좀 더 지속가능한 ASIC저항 계획수립이 시작되어야한다. 정말 ASIC의 지배력을 벗어나지 못한다고 판단되면, 플랜B로 특정 채굴세력이 해시파워를 과독점하지 않는선에서, ASIC을 점진적으로 도입하는 방법까지 고려해야한다. 왜냐면 개인적으로 '탈중앙성'은 비전을 달성하기 위한 수단일 뿐 목적 그 자체가 아니라고 생각하기 때문이다.
    - 어찌됐건, 차기 ASIC저항 포크가 있기전까지 기능 업그레이드를 포함하여 개발 활성화, 커뮤니티의 성장, STO규제 명확화 등을 즐기면 될것같다. 더욱 즐기기 위해서 각자 커뮤니티 일원으로써, 레이븐에 대하여 공부하는 시간을 조금씩 갖기를 권고하면서 글을 마치겠다.

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

[Libra]리브라 개발 업데이트(9월) -로드맵#1 v1.0

9월 Libra Developer Update - 로드맵 # 1

< https://paymentexpert.com/2019/07/05/us-congress-demands-libra-development-to-halt >

□ Libra개발팀의 입장

  6월 공식 리브라 프로젝트 발표 이후, 우리는 개발자 커뮤니티의 반응을 보고 감격했습니다. 개발자들은 여러 블록 체인 탐색기(libranaut, libraview , librabrowser 및 libexplorer)를 출시했고 Libra testnet을 Libra Core에 연결된 PR(코드변경요청)을 포함한 ZenGo과 같은 지갑에 통합했습니다. 우리는 또한 다른 블록 체인 프로젝트가 Move를 시스템에 통합하는 것을 보았습니다(Solana). Calibra팀은 GitHub에서 Libra Core를 계속 개발하고 있습니다.
   우리 개발팀은 또한 Move 응용 프로그램을 로컬로 실행 하기위한 가이드와 자체 네트워크를 실행하는 방법을 보여주는 가이드를 발표했습니다. 그만큼 Libra Discourse Forum은 Transcation scripts, Client development 및 Libra event에 대한 토론이 활발히 진행되고 있습니다. 꾸준한 기술진보와 개방적이고 투명한 대화는 프로젝트에 대한 개발자의 관심을 높이는 핵심요인입니다.

< Libra Mainnet 로드맵 >

□ Testnet를 시작한 이후(Beyond Testnet)

  Testnet을 시작함으로써 팀은 소프트웨어 문제를 쉽게 해결하고 진단하고 해결함으로써 Libra Core를 빠르게 개선할 수있었습니다. Testnet은 Libra 네트워크 기능을 시연하고 개발자에게 제때에 접근권한을 제공합니다.
  Testnet에 이어, 우리는 Libra Mainnet을 성공적으로 출시하기를 희망합니다. 프로젝트 성공을 위한 한 가지 방법은 얼마나 많은 노드들이 배치되어 다른 파트너들에 의해 관리되는지를 보는 것입니다. Mainnet의 최종 목표는 모든 파트너가 네트워크에 노드를 배치하는 것입니다. 각 노드는 사내 및 클라우드 호스팅 인프라가 혼합되어 실행됩니다.
  우리는 다양한 인프라가 Libra 네트워크에 더 나은 유연성을 제공 할 것이라고 믿습니다.

□ GitHub Updates

  개발 진행 상황을 보다 잘 볼 수 있도록 모든 주요 엔지니어링 우선 순위가 포함 된 Kanban 보드(시각화 작업 보드)를 추가했습니다. 이 로드맵의 진행 상황을 여기에서 확인할 수 있습니다. 많은 오픈 소스 프로젝트와 마찬가지로, 기여자들은 기여자 라이센스 계약(Contributor License Agreement)을 따라야합니다.
  우리는 기존의 CLA 승인 프로세스를 간소화하기 위한 몇 가지 옵션을 검토하고 있습니다.
현재 개발 프로세스는 높은 수준의 코드를 적용합니다. 그런의미에서, 우리가 채택한 도구 중 하나는 Homu입니다.
  Homu는 CI/CD(Continuous-Integration/Continuous-Deployment)시스템과 함께 작동하여 테스트를 이행하는 오픈 소스 봇입니다. Homu봇(@bors-libra) PR개정 도중 그리고 다른 PR이 병합된 이후에 테스트가 통과하는지 지속적으로 확인합니다. 여러분은 봇에 태그를 지정하고 그것을 작동하도록 지시하는 PR에서의 명령어를 볼 수 있습니다. 병합 관리에 봇을 사용하는 것은, 테스트를 친환경적으로 유지하려는 대규모 프로젝트에서 흔한 일입니다. 이러한 정책을 브랜치를 보호하고 추가 보안계층을 추가하여, 오직 그 봇으로 하여금 그런 정책을 이행할수 있게 하였습니다.
  엔지니어링 팀은 GitHub문제에 설계 노트를 게시하기 시작했습니다. 어떻게 참여할지 궁금하거나 특정 기능을 추적하고 피드백을 제공하 싶다면 GitHub페이지를 검색하여 주시기 바랍니다. 또한, 우리는 시간이 지남에 따라 참여할 수 있도록 보다 명확하고 풍부한 방법을 제공하기 위해 노력하고 있습니다. 이 로드맵과 향후 로드맵을 게시하고, 우선 순위가 높은 것을 업데이트하고, 설계 노트를 공유하면 향후 Libra Core 기능에 대한 지침과 통찰력을 얻을 수 있기를 바랍니다.

□ 단거리패턴 개발작업(Sprint based Development)

  프로젝트가 시작된 이래, 개발팀은 60일 단거리동안 Libra Core의 계획 및 개발을 안내했습니다. 각 단거리때는 우선 순위별로 구성된 일련의 기능들이 있습니다. 로드맵 #1의 팀은 보안 및 안정성에 중점을 두고 추가 파트너를 향후 Libra Mainnet에 통합하기 위해 노력하고 있습니다.
  로드맵 #1에서 Libra Core의 목표는 보안 및 안정성에 중점을 두고 첫 파트너를 Libra 네트워크 사전 메인 넷에 통합하는 것입니다.

□ 로드맵 #1

  ㅇ 현재 진행 상황
    - 우리는 모든 우선 순위 기능에 대한 설계 작업을 계속 지행하고 완료시킬 것입니다. 우리는 풀노드(Full Nodes)와 같은 기능을 구현하는 데 진전을 보이고 있습니다. 우리는 Libra Protocol 정의를 마무리하기 전에 노드 재구성 사양을 정의하기 위해 노력하고 있습니다.

□ Libra Core

  ㅇ 주소지정/상호운용성
    - 여러 지갑 간의 상호운용성은 Libra 네트워크의 성공을 위한 핵심요인입니다. 개발팀은 하위 계정과의 전송을 지원하는 간단한 체계를 만들기 위해 노력하고 있습니다.

  ㅇ 풀 노드(Full nodes)
    - Libra 블록 체인은 다르게 구성될수도 있는 단일 노드 형식으로 구성됩니다. 이를 통해 노드는 전체 히스토리(전체 노드)를 저장하는 유효성 검증인(벨리데이터) 또는 유효성 검증이 아닌 노드로 작동 할 수 있습니다. 또한, 풀 노드를 유효성 검증인으로 쉽게 업그레이드하거나 그 반대로도 쉽게 업그레이드 할 수 있게 해줄것입니다.

  ㅇ Libra Protocol Definition
    - 우리팀은 API, Wire Spec, 주소지정/상호운용성, 그리고 기타 프로토콜 종속성을 정의하기 위해 노력하고 있습니다.

  ㅇ 검증인 재구성
    - 유효성 검증인 집단은 시스템에서 활성화 된 유효성 검증인의 고유 식별이 포함됩니다. 시간이 지남에 따라, 유효성 검증인 집단은 변경사항을 반영해야합니다. 블록체인 시스템 관점에서 볼때, 유효성 검증인 집단을 변경하면 모든 구성 요소에 영향을 줍니다. 합의는 블록을 재인증하고, 네트워크를 재구성하고, 스토리지는 분산원장 정보를 유지해야하며, 클라이언트는 유효성 검증인 변경사항에서 읽은 데이터를 검증할 방법이 필요합니다.

  ㅇ 경로(Waypoints)
    - 경로는 고객에게 블록 체인 이력에 대한 외부 정보 소스를 제공합니다.

  ㅇ 신뢰 컴퓨팅 기반(TCB, Trusted Computing Base)
    - TCB는 시스템 안전 및 안정성에 중요한 구성 요소의 하위 집합을 정의합니다. 중요한 구성 요소의 하드웨어 및 소프트웨어 종속성을 최소화하면 의도하지 않은 버그 및 악의적 인 공격을 피할 수 있습니다.

  ㅇ 직렬화(Serialization)
    - 우리팀은 유효성 검증 노드간에 RawTransactions를 공유하기 위해 결정적 직렬화(Deterministic serialization)를 구현하고자 합니다. 이 주제에 대한 자세한 내용은 여기를 참조하십시오 .

□ Move

  ㅇ 이벤트
    - Move에서 이벤트를 나타내는 설계 탐구
    - 개발자를 위한 이벤트 API 안정화
    - 개발자가 체인에서 발생하는 이벤트를 기록 할 수있는 방법에 대한 예제 제공

  ㅇ 컬렉션/일반
    - 벡터를 구현하고 지원할 다른 컬렉션 유형 탐색

□ Libra Pre-Mainnet

  프로젝트가 메인넷을 향해감에 따라 테스트넷을 유지하면서 더 많은 노드를 온라인 상태로 만들어야합니다. 이러한 노력을 돕기 위해 Pre-Mainnet이라고하는 준비 환경을 만들었습니다. Pre-Mainnet은 현재 파트너 노드에서만 접근할 수 있으므로 서로 연결할 수 있습니다. 소수의 파트너가 이미 노드를 배포하고 서로 통신하도록 설정했습니다.
  곧 더 많은 파트너가 온라인에 올 것으로 예상됩니다. Libra 네트워크가 액세스를 열기 전에 엄격한 성능 벤치 마킹 및 전반적인 시스템 안정성을 충족시킬수 있도록 할것입니다. 계속 지켜봐 주시기 바랍니다.

□ 개인 논평

  ㅇ 새로운 글로벌 통화를 향하여
    - 지난 6월 Libra출시를 공표한 이후, 수많은 논란과 이슈를 만들며 페이스북의 리브라는 무소의 뿔처럼 혼자서 가고 있다. 미국 의회와 금융 당국은 물론이고, 주요 선진국들의 금융 당국까지 가세하여 새로운 글로벌 통화를 꿈꾸는 이 프로젝트의 금융 안전성, 소비자보호, 자금세탁 등에 대한 심각한 우려를 보이고 있다. 그 뿐만이 아니라, 최근 애플CEO가 민간그룹이 기존통화질서와 경쟁하는 통화를 만드는 아이디어는 불편하다는 말로 고춧가루를 뿌렸고, 페이팔은 Libra프로젝트참여를 거부하는 것도 모자라 중국 온라인결제서비스 시장에 진출함으로써 다된밥에 재를 뿌렸다. 하지만 닭의 모가지를 비틀어도 새벽은 오는 것처럼 Libra는 전진할것이라고 보기 때문에 필자는 Libra에 대한 분석을 이어가고자 한다. 일전에 작성하여 공유한 리브라 관련 글(논평1, 논평2)들이 그 관심의 흔적이다.

  ㅇ Libra 개발에 대하여
    - 필자는 수년간 비트코인, 이더리움 등 여러 프로젝트를 지켜봤기 때문에 Libra분석도 어렵지 않게 할수 있을거라고 생각할수 있지만 꼭 그렇지만은 않다. 왜냐면 새로운 비전과 방향, 다른 개발언어와 환경이 있기 때문이다. 더군다나, 블록체인과 암호화폐 자체도 워낙 혁신적이라 정의하기 어려운데 Libra는 그 가운데서도 여러 의미에서 '새로운 녀석'이다. 그만큼 혁신들 속에서도 역치를 일으킬만한 프로젝트라고 볼수 있다. 개인적으로는 투자없이 분석만 하는 프로젝트이자 지식이 부족해 실물경제를 공부하게 만든 프로젝트라서 부담도 되지만 일단 당분간 개발상황을 지켜보기로 하겠다.
    - Libra의 현재 개발상황은, 아직은 높은 수준이 아닌 기반을 다져가는 수준으로 볼 수 있다. 테스트넷을 통해 개발자들에게 이른 접근권한을 부여하여 초기 개발을 독려하고, Github을 통해 이 오픈소스에 대한 코드수정과 병합을 돕고, 특정 기간을 두어 Libra Core의 다양한 기능들을 설계하고 있다. 시작은 미약할지 몰라도 향후 페이스북이 들어낼 야욕은 여기서 시작되고 있다. 페이스북이 기존 현실금융세계의 원주민들기존 블록체인세계의 원주민들과 어떻게 협력하고 경쟁할지 앞으로 계속 지켜보기로 하자.

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

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

#72 Devs Meeting Review(4 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 (Fri): IstanbulHF EIP soft deadline
   - July 19th (Fri): EIP implementation for clients
   - October 2nd (Wed): Ropsten Testnet HF
   - November : Mainnet HF(=Istanbul HF)

□ Ropsten Fork
  ㅇ What really happened then?
    - Robsten fork occurred two days earlier than the expected date of October 2. Someone was mining with about 1.5 giga hashes and the miner was pushing the existing chain. Now that the miner continues the non-Istanbul chain, which has caused Ropsten network to become unstable and many of the nodes are non-Instanbul nodes, we have been figuring out what is going on in the network.

    - Although Geth client users filter the non-Istanbul chain, Parity client users are not sure. In fact, we have several options to prevent this situation in the future. But in Ropsten's case, it's too late to add a correction.

    - Devs issued some problems the last time they worked at Ropsten, but no one contacted them. However, although they thought it was a good test for chain handling before, the devs were not happy. Nevertheless, it is very interesting to watch how clients behave in order to continue the longer chain.

    - Ropsten crisis has happened anyway, but there is no big concern at mainnet because it doesn't see much chance of the Istanbul chain being pushed out by the giant miners.

□ Ethereum Roadmap 2020: Community discussion (Debcon5)
  ㅇ Ethereum Community Debate at Devcon5
    - On the first day of Devcon 5, there will be sessions to discuss roadmap for Ethereum1.0, 1.x and 2.0. If you are interested, please join us and discuss it with our key devs.

 < Community Debate Overview >
  ㅇ When : October 8, 2019 (1-5 p.m.)
  ㅇ Where: Convention room (200 seats or more)
  ㅇ What : Discussion organized by the Ethereum Magicians for those who contributed to Ethereum1.0 and Ethereum2.0
   ※ Click here for more information 

□ Ice Age
  ㅇ Time to release the ice age
    - The Ice Age EIP will not be included in Istanbul Falk because it has no specific cause. Now Istanbul is defined and Ropsten fork has occurred, so it is impossible to apply the ice age. Also, according to the calculations of some developers, the ice age should be taken enough time to apply to another fork rather than to include it in Istanbul.

□ Testing updates
  ㅇ Fork ID definition
    - Anyone who has an objection to the Geth team, which defines Eth64 as a fork ID* and wants to roll out, will challenge AllCoreDevs within two weeks.
    *ForkID : A unique identifier of the block chain, created to distinguish it from the unique identifier(ID) of the existing main chain at fork time. If the fork ID is newly defined, problems such as replay attack can be prevented before long.

  ※ Confirmed EIPs for 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. 

□ Personal comments
  ㅇ Fork and job verification method
    - Ropsten, one of Istanbul testnets, had a fork earlier than expected because it was mined as quickly. In other words, the time spent verifying the block has been reduced than usual. As is well known, when a fork occurs, it is important for the miner's will and cooperation to be as important as the miner's new version must be upgraded directly to match the fork.

    - But in the case of Ropsten fork, the network became unstable, with a huge hash dominator running an existing chain rather than a fork chain and confused about what version of the chain nodes should follow, where non-minor ether holders only have ether in their wallets as safe as possible and nothing can be done. This is the characteristic and disadvantage of proof of work(PoW). If ether was based on proof os staking(PoS), it is granted distributed authority to contribute to the maintenance of the direct network by depositing the principal Eider as a valid stake and taking part in the verification. So I am looking forward to Ethereum 2.0 coming soon.

    - There are already many projects that utilize the equity method, but I wonder what kind of enormous movement Ethereum, the second-largest project in total, will portray to enhance its scalability, including the conversion of the consensus protocol. Personally, I am as excited and worried as when I do hard fork after DAO hacking. In that sense, let’s first carefully watch for the rest of 2019 to see if Istanbul forks scheduled for November are successfully implemented and are well prepared to switch to Ethereum 2.0 by the end of the year.

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월 02일(수) : Ropsten Testnet HF
     - 11월 중 : Mainnet HF(=Istanbul HF)

□ Ropsten Fork 정리

  ㅇ 무슨일이 어떻게 발행했나
    - 롭스텐 포크는 예상일인 10월 2일보다 2일 일찍 발생하였다. 누군가가 약 1.5기가 해시를 갖고 채굴하고 있었고 그 채굴자는 기존체인을 밀고 있었다. 현재 그 거대 채굴자는 비(非) 이스탄불 체인을 이어가고 있으며, 그탓에 롭스텐 네트워크가 불안해졌고 많은 노드들 역시 비(非) 이스탄불 노드들이기 때문에, 우리는 그 네트워크에서 무슨일이 벌어지고 있는지 파악해오고 있다.
    - Geth 클라이언트 사용자들로 하여금 비(非) 이스탄불 체인을 걸러내고 있지만, Parity 클라이언트 사용자들은 잘 모르겠다. 사실 우리는 미래에 이런 상황을 방지할수 있는 몇가지 선택지가 있다. 하지만 롭스텐의 경우, 수정을 추가하기엔 너무 늦었다.
    - 개발자들은 롭스텐에서 마지막으로 작업했을때 몇가지 문제들이 발행했지만 누구도 연락하지 않았다. 다만, 이전에만 하더라도 체인을 다루는데에 좋은 테스트라고 생각했지만, 디앱 개발자들의 기분이 좋지 않았습니다. 그럼에도, 더 긴 체인을 이어가기 위해 클라이언트가 어떻게 행동하는지 지켜보는 것은 매우 흥미롭다.
    - 어쨌든 롭스텐 사태가 발생했지만, 메인넷에서는 거대 채굴자들에 의해 이스탄불 체인이 밀려날 가능성이 크지 않다고 보기 때문에 큰 걱정은 하지 않는다.

□ 이더리움 로드맵 2020 : 커뮤니티 토론(데브콘5)

  ㅇ 이더리움 커뮤니티 토론 at Devcon5
    - 데브콘5 첫날 이더리움1.0, 1.x, 2.0의 로드맵을 논의하기 위한 세션이 있을것입니다. 관심이 있는 분들은 여기에 참여하여 핵심개발자와 토론하시기 바랍니다.

 < 커뮤니티 토론 개요 >
    - 일시 : 2019년 10월 8일(목) 오후1~5시
    - 장소 : 컨벤션 룸(200석 이상)
    - 내용 : Ethereum1.0과 Ethereum2.0에 기여한 사람들과 이해당사자들을 위한 Ethereum magicians이 조직한 토론회
   ※ 자세한 내용은 여기 클릭

□ 빙하기(Ice Age)

  ㅇ 빙하기 해제 시기
    - 빙하기 EIP는 특별한 명분이 없기때문에 이스탄불 포크에 포함시키지 않을것이다. 현재 이스탄불이 정의되어있고 롭스텐 포크가 일어났기 때문에 빙하기를 적용하는것은 무리가 있다. 또한 일부 개발자의 계산에 따라서, 빙하기를 이스탄불에 포함시키기 보다는 또다른 포크에 적용하기 위한 충분한 시간을 갖기로 한다.

□ 테스팅 업데이트

  ㅇ 포크ID정의
    - Eth64를 포크ID*로 정의하고, 롤아웃하자는 Geth팀에 반대의견이 있는 사람은 2주이내에 AllCoreDevs에 이의를 제기한다.
     *포크ID : 블록체인의 고유 식별자로, 포크시 기존 메인체인의 고유 식별자(ID)와 구분하기 위해 생성된다. 이렇게 포크ID가 새로 정의되면 리플레이 어택 등의 문제를 미연에 방지될수 있다.

   ※ 이스탄불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사용을 불허함.

□ 개인 논평

  ㅇ 포크와 작업증명방식
    - 이스탄불 테스트넷 중 하나인 롭스텐이 예상보다 일찍 포크가 발생하였는데, 그 이유는 그만큼 빨리 채굴되었다는 것이다. 즉, 평소보다 블록을 검증하는 데 걸린 시간이 줄어들었단 말이다. 익히 알려진대로, 포크가 발생하면 채굴자들은 포크에 걸맞는 새로운 버전을 직접 업그레이드해야하므로, 그만큼 채굴자의 의지와 협조가 중요하다.
    - 하지만 롭스텐 포크의 경우, 엄청난 해시를 지닌 채굴자가 포크체인이 아닌 기존체인을 이으면서 노드들이 어떤 버전의 체인을 따라야하는지 혼란스러워 하는 등 네트워크가 불안해졌고 여기서 비(非) 채굴자인 이더 보유자들은 최대한 안전한 지갑에 이더를 보유할 뿐 딱히 할수 있는것이 없다. 이것이 바로 작업증명방식(PoW)의 특징이자 단점이다. 만약 이더가 지분증명방식(PoS)이었다면 본인 이더를 유효지분으로 예치하여 검증에 참여(Staking)하면 직접 네트워크 유지에 기여할수 있는 분산된 권한이 주어진다. 그래서 곧 다가오는 이더리움2.0이 기대된다.
    - 지분증명방식을 활용하는 프로젝트가 이미 많이 있지만 시총2위의 거대 프로젝트인 이더리움이 합의프로토콜의 전환을 포함하여 확장성을 높이는 어마어마한 움직임이 어떤 모습을 그릴지 궁금하다. 개인적으로는 DAO해킹이후 하드포크를 할때만큼 또는 그 이상으로 설레고 걱정이 된다. 그런의미에서 우선 2019년 남은 기간동안, 11월쯤으로 예정되어있는 이스탄불 포크가 성공적으로 이행되는지와, 연말까지 이더리움2.0의 전환 준비가 잘 되고 있는지 주의깊게 지켜보도록 하자.

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

[Ethereum] 이더리움2.0개론(Introduction to Ethereum2.0)(ft.서울이더리움밋업) 2부 v1.3

이더리움2.0개론(Introduction to Ethereum2.0) Part.2

  다음으로는 이더리움2.0 즉 세레너티를 단계별로 살펴보겠습니다.
  먼저 0단계에서는 비콘체인이 도입되어 PoS시대를 엽니다이 비콘체인은 1)검증인 및 그들이 예치한 유효지분을 관리하고, 2)추후 생길 샤드상에서 블록제안자를 지명하고3)그 제안된 블록에 대한 투표를 하기 위해 증인위원회를 구성하고, 4)합의규칙과 보상 및 패널티를 정의합니다0단계의 특징으로는유효지분을 통한 검증 즉 스테이킹을 개시하여 보상 또는 페널티를 받을수 있고비콘체인과 추후 생길 샤드체인의 가교 역할을 할 크로스링크를 만들어 이런저런 시뮬레이션을 합니다.
  그 다음 단계인 1단계에서는 샤드체인이 도입되어 샤딩시대를 엽니다앞서 설명한대로 샤드체인이 도입되면 스테이트를 분할하고 트랜잭션을 병렬 처리할수 있는데 아직 이 단계에서는 데이터를 저장하는 수준에 머무를겁니다1단계에의 특징은방금 말씀드린대로 샤드를 도입하여 데이터체인을 구축하고크로스링크를 통해 갹 샤드의 데이터를 확정하고그 데이터의 가용성을 증인위원회가 검증합니다.
  그 다음 단계인 2단계는 앞서 도입된 샤드체인이 본격가동되고 스테이트를 실행함과 동시에 새로운 가상머신인 eWASM이 도입됩니다특히 이 eWASM은 갹 샤드에서의 스테이트컨트렉트를 실행 및 관리를 적극 지원합니다2단계의 특징은 앞서 설명한대로 사용자가 스토리지에 저장하는 데이터의 양과 시간에 비례하여 수수료를 내고이때서야 비로소 PoS버전의 이더를 거래소나 다른 사람에게 자유롭게 전송가능합니다
  다음으로 살펴볼 대목은 이더리움2.0에서의 경제분야입니다일단 이더보유자엄밀히 말하면 적어도 32이더를 보유한 자는 누구나 비콘체인 도입 직후 그 이더를 디파짓 컨트렉트에 마이그레이션하여 스테이킹을 할수 있습니다이 마이그레이션은 네트워크 유지관리의 근간이채굴기라는 외부요인이 아닌 각자가 지닌 유효지분이라는 내부요인으로 전환하는데 큰 의의가 있습니다.
  그렇게 스테이킹을 하면 얼마나 검증에 참여했는지에 따라 연간 발행량과 발행률스테이킹 이율이 달라집니다발행량과 발행률은 좀이따 살펴보기로 하고 먼저 스테이킹 이율을 보면 검증참여가 적을수록 스테이킹이율이 높습니다아마도 스테이킹이 개시된 직후엔 스테이킹 이율이 상당히 높을 것입니다다만초기 스테이킹한 사람들은 2단계까지 어디든 전송이 불가한 기회비용은 있겠죠여튼 검증참여는 시간이 지나면서 일정수준으로 수렵될텐데 최소 3천만 이더가 검증에 참여할것 같습니다그럴 경우 3프로대의 이율이 되는데 어찌보면 적은 이율일수 있습니다그래서 한때 뷰터린이 이 이율을 좀 더 높일 필요가 있다고 언급한 적도 있습니다참고로 이 표는 예측치일 뿐이므로 실제와 다를수 있음을 말씀드리는 바입니다
  다음으로는 아까 방금 잠깐 살펴본 발행률에 대한 것입니다Frontier때는 인플레이션이 상당히 높게 되어있지만 난이도 폭탄이 터지는 2017년 초부터 인플레이션이 급감합니다그러다가 난이도 폭탄이 연기되면서 잠시 반등하는데 2019년 초에 또한번 난이도폭탄이 터지면서 다시 하락합니다
  그 이후 인플레이션이 약간 상승할때가 있는데 이때가 바로 0단계에서 스테이킹이 시작될때인데 이때는 PoW에서의 채굴과 PoS에서의 민팅이 막 공존할때이기때문에 살짝 늘어납니다하지만 나중에 2단계때쯤 되면 PoW체인의 채굴보상을 완전 낮아질것이기 때문에 이더의 발행율은 거의 제로가 됩니다여기서 끝이 아닙니다그때쯤이면 PoS에서의 트랜잭션 수수료페널티 등으로 모여진 이더를 소각하는 정책이 도입되므로 마이너스 발행율 시대가 될것으로 보고 있습니다.
  여태까지 기술적인 관점으로 살펴봤다면이번에는 우리가 익히 배운 1,2,3차 산업구조의 관점으로 이더리움의 역사를 살펴보겠습니다
  농축수산업으로 대표되는 1차산업을 이더리움으로 옮겨보자면 Ethereum1.0이자 채굴업일겁니다이때는 보상을 통한 네트워크 유지 동기부여 및 보안관리그리고 채굴을 통한 확고한 팬덤과 커뮤니티 확보가 가능했습니다.
  생산제조업으로 대표되는 2차산업을 이더리움으로 옮겨보면 Ethereum1.x이자 토큰제조업일겁니다ERC-20을 포함한 여러 ERC버전을 통한 디앱토큰 등이 생성되었고, ICO 등 펀드레이징에 이더가 활발하게 활용되었습니다.
  그리고 서비스업으로 대표되는 3차산업은 Ethereum2.0이자 이더리움 서비스업 시대라고 볼수 있습니다이때는 이더리움이 블록체인서비스업의 선두주자로 발돋움하여 Blockchain as service를 통한 익명성경제성 등 기존문제를 해소하고Staking as service를 통해 Decentralized Finance를 잘 구성하여 전통적인 금융서비스 대체 및 Defi가 활발해지기를 기대합니다.
  제가 앞서 설명한 것들을 토대로 이쯤되서 궁금해할만한 질문을 스스로 5개정도 선정해봤습니다
  첫번째로, Ethereum2.0에서 확장성 향상은 명확히 예측하기 어렵지만 단순하게 보면 현재 평균치인 14tps에 총 샤드갯수인 1,024를 곱한 약14,000tps가 될수도 있습니다.
  두번째로, PoS로 전환시 페널티의 종류는 크게 2가지입니다. 하나는 우리가 일반적으로 알고 있는 시빌공격(Sybil attack)이 있는 경우 악의적인 행위를 한다고 의심되는 검증자로부터 최소 1eth를 삭감시키는 Slashing이 있습니다. 다른 하나는 검증 즉 스테이킹 도중에 정전 등으로 오프라인이 된경우 그 검증자는 악의자로 간주되어 유효지분이 지속 삭감되는 Inactivity leak이 있습니다. 여기서 주목할만한 점은, 이 오프라인되는 시점이 재수없게 총 검증인의 1/3이상이 오프라인된 시점이라면 블록체인 확장성에조차 악영향이 가기때문에 상당량의 유효지분이 삭감될것입니다.
  세번째로, PoS버전의 ETH는 샤드체인이 본격적으로 가동되는 Phase2때쯤 비로소 거래소에서 거래가능하거나 다른 사람들에게 송금가능합니다.
  네번째로, Ethereum2.0에서의 우려되는 점들은, 검증참여가 너무 낮거나 높거나, 샤딩이 생각보다 복잡하거나, 또는 노드운영이 비경제적이어서 진입장벽이 높은 점입니다.
  다섯번째로, Ethereum2.0을 넘어서서 진정한 Full PoS에서의 World Computer의 면모를 보일 Ethereum3.0에서의 주요특징은 첫째도 STARKs, 둘째도 STARKs, 셋째도 STARKs,입니다. 이는 영지식증명에서 가장 진보된 기술로서 익명성 뿐만 아니라 확장성, 양자컴퓨터 저항성 등이라는 이점을 지니고 있습니다.

  지금까지 제가 이더리움2.0을 나름대로 자세하게 설명했지만이 모든게 순조롭게 이행되려면 각자의 노력이 필요합니다
  첫번째로이더리움 마법사라고 볼수 있는 개발자의 역할입니다이들은 여태 그래왔던것처럼 EIP를 제안하고 테스팅하고 구현과정을 최적화하는데 최선을 다해야할것입니다또한 아직은 많이 부족한 User Experience와 User Interface를 개선해야합니다.
  두번째로이더리안이라고 볼수 있는 사용자입니다이들은 언제든 이더리움을 경험하고 느끼는 장단점을 피드백하고 개선점에 대한 어필을 해야합니다.
  그리고 마지막으로 이더리움의 버팀목이 될 커뮤니티의 역할입니다단순 지지자부터 이더를 홀딩하고 있는 투자자로 구성된 이들은 비판적 사고를 갖고 꾸준한 관심과 인내를 가져야합니다또한 이더리움 비전이 높다고 판단되면 이더 보유분으로 스테이킹 특히 초기에 동참해야합니다. 
29차 서울이더리움밋업에서 발표하는 오공(필자) >

  이상으로제가 준비한 이더리움2.0 개론에 대한 내용이었습니다. 비트코인 뿐만 아니라 이더리움을 오랜간 지켜보면서 느낀건 이 블록체인과 암호화폐 시계가 빨리 돌아가는 것 같으면서도 어쩔땐 너무 더디게 간다는 느낌이 들었습니다. 그것은 아마도 분석할때와 투자할때 마음가짐이 달라서이기도 할겁니다. 극심한 변동성과 말도안되는 사건사고가 많은 탓에 잠을 설쳐서 삶의 질이 낮아진것 같기도 하지만 이 분야를 알면서 자본주의의 이면과 새로운 혁명덕분에 가슴이 설레이기도 합니다. 따라서 그 결과가 어떻든 이런 과정을 다 같이 논하고 경험하며 즐겼으면 합니다. 
  아무쪼록, 조만간 도래할 이더리움2.0시대에 많은 관심과 지지 부탁드리며 부족한 자료를 봐주신 여러분들에게 감사말씀드립니다.

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

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

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