[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의 전환 준비가 잘 되고 있는지 주의깊게 지켜보도록 하자.


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

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

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