[Raven] Raven Devs Meeting(21 June, 2019) // 6월 21일 레이븐 개발자 회의 분석 및 개인 논평 v1.1


(English) 한국어 버전은 아래쪽에 있음

□ Analysis of the meeting by subject

  ㅇ Wallet Support
    - Ravencoin has really been succeeded in the last few weeks, with more exchanges and wallets supporting Ravencoin. You need to look at the companies that produce these new products.
    - You need to be very careful and make sure once again that the company will not cheating you.
    - Please check the website URL again, and copy and paste an address while checking if the address is correct before sending or withdrawing.
    - If you Firefox, please update to the latest version (67.0.4) because there was a hack in the previous version.

  ㅇ Current status of 'Dividends' and 'Rewards'
    - Recently, devs of Dividends and Rewards provided pull request, which makes it possible to code reivew, feedback for this open source devs at a distance. We are now verifying the coding. If this collaboration goes well, we will put it onto the testnet, and then anyone can try to transfer transactions on the network and will test dividends and rewards functions.

  ㅇ Current status of 'Restricted assets'
    - Restricted assets are ready to be put on testnet. However, it will not happen until June 24 that the testnet node will be ready for its launching. We will wait until other users join us, and the announcement will be made on Monday(June 24).

  ㅇ Coinpayments service
    - Coinpayments supports ravencoins, which enables the payment of ravencoins in thousands of stores and will make it easier for many companies to use ravencoins as a payment platform. Vinsent, which makes wine futures contracts, can also use raven to pay for wine purchases through Coinpayments.

  ㅇ Current status of Rewards development
    - Rewards will be deployed on testnet after it has safely been verified. There is no specific time set, but it will take at least  a couple of weeks until then.

  ㅇ x16r FPGA Issues
    - A dev asked what plan Raven Core Dev team had for the x16r FPGA and Tron Black says he has no plans, because the FPGA is already as fast as GPUs and is not that dominent on the whole(Foodnote : Unlike ASIC, FPGA is difficult to react to and does not have a high degree of control to respond to).
    - When asked how Tron would respond to the FPGA, he also mentioned Moreno's way saying that he could develop a new PoW by CPU that surpasses ASIC, FPGA and even GPUs. Now he looks at that Monero's way again ASIC.


□ Personal Review

  ㅇ 'Development' of 'Devs' 
    - Devs first mentioned the agenda of the meeting at it beginning for the first time since I have monitored. In analysing Raven devs meeting, I find it difficult to summarize in order as they usually ramble on their talk.
    - However, I was able to summarize the meeting more easily and feel that the development of the Raven project is in its progress well. For analysts or investors like me who are care about its details, this well-organized meeting seemed to be a much more promising project.
    - And as you saw other news and articles about Raven project, significant developments including various features and some testnets are currently underway, and more exchanges and wallets/payments support and adopt Ravencoins as mentioned earlere. Sometimes the 'Black bird' looks like it rests on a tree, but we will see soon that it flyhigh in the sky in the end.

  ㅇ ASIC survey
    - ASIC-related surveys proposed by Raven devs are currently underway. It has 6 items on ASIC issue, top priority of Raven devs and community. It does not take much time, so please be sure to participate.
    - You can visit here to join the survey : https://www.surveymonkey.com/r/W29S96N



(한국어)

□ 소재별 회의 내용

  ㅇ 지갑 지원
    - 레이븐코인은 지난 몇 주간 정말 대단한 성공을 거두었는데, 더 많은 거래소와 지갑이 레이븐코인을 지원하고 있다. 이에 여러분들은 이러한 신제품을 생산하는 업체를 잘 살펴봐야 한다.
    - 업체가 당신을 속이는 것이 아닌지 다시 한 번 확인하는 등 상당한 주의가 필요하다.
    - 웹 사이트 URL을 다시 확인하고, 입출금 이전에 상대 주소가 맞는지 확인하면서 주소를 복사 및 붙여넣기를 하길 바란다.
    - 혹시 파이어폭스(Firefox)를 사용한다면, 이전 버전에서 해킹이 있었으므로 최신버전(67.0.4)으로 업데이트하십시오.

  ㅇ 배당(Dividends)과 보상(Rewards) 현황
    - 최근에 배당 및 보상 관련 개발자가 관련 사안을 레이븐 깃헙에 Pull Request(필자주 : 각자 떨어져 있는 이들을 위해 오픈소스 프로젝트의 코드 리뷰, 피드백 등 협업을 가능케하는 기능)해놨다. 현재 우리는 해당 코딩을 살펴보고 검증하고 있다. 이 협업이 잘 성사되면, 우리는 일단 테스트넷에 올릴것이며, 올려지면 누구든 네트워크상에서 트랜잭션 전송하는 방법 등을 시도할수 있고 배당 및 보상을 생성하는 것을 테스트할수 있을것이다.

  ㅇ 제한자산(Restricted Assets) 현황
    - 제한자산은 테스트넷에 올려질 준비가 되었다. 하지만, 월요일(6월 24일)이 되어서야 테스트넷 개시 노드가 준비될것이기에 그때까지는 다른 테스트넷 사용자들이 합류할때까지 기다릴것이며, 월요일(6월 27일)에 관련 공지가 나갈것이다.

  ㅇ 코인 결제 서비스 관련 안내
    - Coin payments라는 업체가 레이븐코인을 지원하게 되었고, 이를 통해 수천개의 상점에서 레이븐코인이 결제가능하며 결제플랫폼으로서 많은 업체에서 레이븐코인을 쉽게 사용될수 있게 되었다. 와인 선물계약을 하게 하는 Vinsent사도 Coin payments를 통하여 와인구매 결제시 레이븐이 활용가능하다.

  ㅇ 보상(Rewards) 개발 현황
    - 보상 기능은 안전성이 검증된 이후에 테스트넷에 올려질것이다. 특정 시기는 정해져있지는 않지만, 개인적으로 그때까지 최소한 1~2주정도 소요될것으로 본다.

  ㅇ x16r FPGA 이슈
    - 한 개발자가 레이븐 코어 개발자팀에서 x16r FPGA에 대하여 어떤 계획을 갖고 있는지 물었다. 이에 Tron Black(이하 '트론')은 어떠한 계획도 없다면서, 그 이유로 FPGA는 지대한 영향력이 없고(Not that dominant), (이미) GPU만큼 빠르기 때문이다(필자주 : ASIC과는 달리 FPGA는 대응하기에도 어렵고 그렇다고 대응하기엔 그 지배력이 높지 안하는 의미).
     - 또한 FPGA에 대한 대응은 어떻게 할거냐는 질문엔, 모레노의 대응방식을 언급하면서 AISC, FPGA, 그리고 심지어 GPU를 능가하는 CPU에 의한 새로운 PoW방식을 고안할수 있다고 말했고 트론 역시 그러한 모네로의 방식을 주시하고 있다고 말했다.


□ 개인 논평

  ㅇ '개발'자 회의의 '개발'
    - 레이븐 개발자 회의를 보면서 거의 처음으로 본격적인 회의 시작전에 안건에 대해 정하였다. 레이븐 개발자 회의를 정리하면서 아쉬운 점이 있다면 두서없이 이 안 저 사안을 넘나들며 논의한다는 점인데, 개인적으로 정리하고 분석하는데 상당한 어려움이 있었다.
    - 하지만 이번 회의때는 초반 안건들에 대한 언급덕분에, 좀 더 수월하게 레이븐 개발자 회의를 정리할수 있었고, 왠지 레이븐 개발 현황마저 더 매끄럽게 진행되는 느낌마저 들었다. 이게 별것 아닌것같아도 디테일도 놓치지 않는 분석가이자 투자자로서는 이런 점점 더 발전하는 프로젝트가 될거라고 더욱 기대하게 되는 점으로 보였다.
    - 그리고 다른 레이븐 글 작성자나 레이븐 기사 등을 통해서 보셨다시피, 현재 레이븐 플랫폼의 여려 기능들이 검증되거나 테스트넷에 올려지는 등 유의미한 개발이 진행되고 있고, 개발자 회의에도 언급되었듯이 더 많은 거래소와 지갑/결제업체가 레이븐코인을 상장 및 채택하고 있다. 가끔은 나무에 걸터앉아 쉬는것같아 보이지만 당장이라도 하늘높이 날아갈 큰 까마귀의 비상을 좀만 더 기다려보자.

  ㅇ ASIC 관련 설문조사
    - 레이븐 개발자들이 제안한 ASIC관련 설문조사가 현재 진행중이다. 레이븐 개발진과 커뮤니티가 가장 중요하게 생각하는 ASIC의 대응에 대한 6개 항목으로, 시간이 많이 걸리지 않으니 반드시 참여하길 바란다.
    - 여기를 방문하여 설문조사에 참여할수 있다. https://www.surveymonkey.com/r/W29S96N



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

[Ethereum] '제63차 이더리움 개발자 회의' 분석 및 개인 논평 v1.0

<제63차 이더리움 개발자 회의 안건>

https://github.com/ethereum/pm/issues/102



□ 지난 회의 리뷰(+추가 검토)

  ㅇ 협의한 사안과 결정
    - EIP-1108을 이스탄불HF에 적용하기로 임시승인(a tentative approval)하고, 최종승인될때까지 추가 검토가 필요하다.

  ㅇ EIP-1109(https://eips.ethereum.org/EIPS/eip-1109)
    - PRECOMPILEDCALL이라는 특정 opcode를 생성하여, 일반 CALL실행시 어떤 비용없이 프리컴파일된 컨트렉트를 호출하게한다. 이는 프리컴파일된 컨트렉트들을 호출할때 높은 가스 소비를 하게되는 문제를 해결하기 위함이다.
    - 이 EIP는 오래전에 제안되었지만 내용을 많이 바꿨고 이번에 제대로 제안하여 다가올 HF에 적용하기로 하였다.

  ㅇ EIP-1962(https://eips.ethereum.org/EIPS/eip-1962)
    - 타원 산술 및 런타임 정의와 결합에 대한 개선안으로, EIP-1829에 대한 확장안이며 EIP-1109에서의 SATICCAL opcode보다 작업비용이 더 저렴하다.
    - 추가로 할말은 딱히 없다.

  ㅇ EIP-1283(https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1283.md)
    - 기존 콘스탄티노플HF에 적용될뻔한 EIP로, 총 가스 계량기(Net gas metering)를 변경하여 컨트렉트 저장소를 위한 새로운 활용가능성과 대부분의 작동방식이 안 맞을때 발생하는 과도한 가스비 감소에 도움이 된다. 즉, 불필요한 가스비를 줄이는 코딩을 가능케한다.
    - EIP-1706와 관련되어있는 기존 콘스탄티토플HF 적용 후보EIP로, 그때에 비해 큰 변화는 없으며 관련 개발자가 추가되었다. 다만, 이스탄불HF에 적용시 이 두 EIP(1706, 1283)가 결합되어 적용될수도 있으나 아직 합의가 되지 않기 때문에 검토가 필요하지만, EIP-1283은 지난 HF에도 적용될수도 있었던 제안으로, 이미 준비가 되었기에 이스탄불HF적용되었으면 한다. 그전에 EIP-1283팀 간에 합의를 통해 최종 의견을 내세울테니 그때 최종승인할지 다뤘으면 한다.

  ㅇ EIP-2045(https://github.com/ewasm/benchmarking)
     - 블록가스한도를 높이는(스토리지opcode비용을 높이는) 대신 계산opcode 가스비를 절감한다.
     - 최적화된 인터프리터에서 EVM바이트코드를 실행(evmone)해보니 꽤 괜찮은 성능을 보여주었다.
     - 이스탄불HF 적용을 위해 아직까지 개발자 회의에 소개할 내용은 충분하지 않는 실정이며, 계속 같이 논의하기로 하자.

  ㅇ EIP-2024(https://github.com/ethereum/EIPs/pull/2024/files)
    - BLAKE2b라는 새로운 암호화 해싱 알고리듬을 구현하는 사전컴파일 컨트렉트를 EVM에 도입하는 것으로, 이 BLAKE2b는 SHA해시함수보다 빠르고 효율적이며, SHA-3을 보완 및 대체가능하다. 또한 이 알고리듬은 64bit CPU에 최적화되어있고, Zcash블록체인과 EVM간 상호 운용성을 개선하고 IPFS와의 통합을 지원한다.
     - 이 알고리듬을 효율적으로 사용하면, Zcash에서 사용하는 Equihash에 의한 검증이 가능하며, 이더리움 상에서 BTC relay SPV방식*을 가능케하기도 한다.
      *BTC relay : 비트코인을 사용하여 이더리움 기반의 서비스를 이용케하는 체인간 중계 프레임워크로, 중계시 비트코인 풀노드(블록체인상 모든 블록정보를 저장하고 채굴하면서 새로운 블록을 생성하는 노드)를 모니터링 및 저장하는 중계자(relayer)가 있다. 그런데 풀노드의 모든 블록정보를 스마트컨트렉에 저장하기에는 너무 비효율적이므로 블록헤더만 저장하여 유효성 검증하는 SPV(Simplified Payment Verification)방식으로 비트코인 정보를 이더리움의 스마트컨트렉에 기록한다. 이때 더 간편한 SPV방식 덕분에 더 효율적인 유효성 검증이 가능하며, 수수료가 발생하기에 중계자들은 중계하는 행위에 동기부여가 되며, 결국 이러한 과정을 통하여 비트코인을 사용하여 이더리움 어플리케이션을 실행할수 있다.


□ 로드맵(https://en.ethereum.wiki/roadmap/istanbul) 

   <이스탄불 HF 로드맵>
     - 05월 17일(금) : 이스탄불HF EIP 접수 확정기한
     - 07월 19일(금) : 주요 클라이언트 실행 마감기한
     - 07월 중 : 핵심개발자 미팅(예정)
     - 08월 14일(수) 테스트넷에서의 네트워크 업그레이드*(Ropsten, Gorli, 또는 다른 임시 테스트넷)
      * 19.1월 비탈릭이 포크 대신 네트워크 업그레이드라고 부르고, 체인분기가 일어나는 경우만 하드포크라고 부르기를 이더리움 커뮤니티에 제안한 바 있음.
     -10월 16일(수) 메인넷에서의 네트워크 업그레이트(=이스탄불 HF)

    <이스탄불 HF에 포함될 EIP후보 목록> 
     : 아래 EIP들은 이스탄불 여정에 동행할 후보들로, 핵심개발자들의 승인, 실행, 테스트, 감사, 그리고 다른 작업들이 필요하며, 지속 논의될 예정이다. 자세한 설명은 각EIP링크 또는 이더마술사 EIP포럼(여기 클릭)을 참조 요망
     0> EIP-1679(https://eips.ethereum.org/EIPS/eip-1679)
       - 이스탄불 HF 상황체크용 '메타 EIP'로, 여기서 언급할 EIP들중 '선임 EIP'라고 할 수 있다.
       - 이 메타 EIP는 '이스탄불'로 불리우는 이더리움HF에 포함된 수정사안들을 구체화하기 위함이며, 아직 세부적인 내용은 없는 상태이나 추후 이스탄불HF윤곽이 들어나면서 내용이 추가될 예정이다.

     1> EIP615(https://eips.ethereum.org/EIPS/eip-615)
       - EVM을 위한 서브루틴(subroutines) 및 정적 점프(static jumps)다. '서브루틴과 연산기법을 도입하여 성능향상 등 검증의 최적화를 위한 작업'정도라고 보면 된다.
(자세한 설명은 여기글 후반부를 참조)

     2> EIP-663(https://eips.ethereum.org/EIPS/eip-663)
       - 현재 SWAP과 DUP명령어는 스택상 16의 깊이로 한정되어있는데, 이들과 대응되는
SWAPn과 DUPn을 1024개의 아이템의 모든 깊이까지 접근을 허용한다.

     3> EIP-1057(https://eips.ethereum.org/EIPS/eip-1057)
       - ProgPoW는 특정ASIC이 채굴할수 있는 작업유효간격을 좁히기 위해 고안된 PoW알고리듬으로, ASIC의 향상된 효율성을 반감시키위하여, 상용GPU자원을 최대한 활용되도록 수정하는 것이 ProgPow의 디자인이다.

     4> EIP-1108(https://eips.ethereum.org/EIPS/eip-1108)   *임시승인됨(62차 회의)
       - alt_bn128 프리컴파일 가스비 절감제안서다. 값비싼 타원곡선산술 사전컴파일을 재평가하여 개인정보보호와 확장성을 개선하고자 한다.

     5> EIP-1109(https://eips.ethereum.org/EIPS/eip-1109)
       - PRECOMPILEDCALL이라는 특정 opcode를 생성하여, 일반 CALL실행시 어떤 비용없이 프리컴파일된 컨트렉트를 호출하게한다. 이는 프리컴파일된 컨트렉트들을 호출할때 높은 가스 소비를 하게되는 문제를 해결하기 위함이다.

     6> EIP-1283(https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1283.md)
       - 기존 콘스탄티노플HF에 적용될뻔한 EIP로, 총 가스 계량기(Net gas metering)를 변경하여 컨트렉트 저장소를 위한 새로운 활용가능성과 대부분의 작동방식이 안 맞을때 발생하는 과도한 가스비 감소에 도움이 된다. 즉, 불필요한 가스비를 줄이는 코딩을 가능케한다.

     7> EIP-1344(https://eips.ethereum.org/EIPS/eip-1344)
       - 컴파일링시 체인ID를 지정하고 opcode를 추가하면 그 체인ID에 접근하여 서명의 유효성을 검사하며, 이는 다른 체인간 리플레이 어택 등을 방지할수 있다.

     8> EIP-1352(https://eips.ethereum.org/EIPS/eip-1352)
       - 사전컴파일과 시스템컨트렉트가 차지하는 이더리움 주소 범위를 지정하고자 한다.

     9> EIP-1380(https://eips.ethereum.org/EIPS/eip-1380)
       - 자기호출에 대한 가스비 절감으로, 현재 로드된 컨트렌트의 새 인스턴스를 실행시 호출지시에 대한 가스비를 줄이고자 한다.

     10> EIP-1559(https://eips.ethereum.org/EIPS/eip-1559)
       - 현재의 비요율적이고 불필요한 가스비가 드는 방식을 벗어나, 네트워크 수요에 따라 기본 네트워크 요금을 조정하고 비용 효율성을 높이며 가스비지불에 있어 사용자 편의성을 높이는 새로운 방식이다. (자세한 설명은 여기글 후반부를 참조)

     11> EIP-1965(https://eips.ethereum.org/EIPS/eip-1965)
       - 체인ID(서로 다른 체인간 트랜잭션 재생을 방지하는 수단)가 특정 블록넘버에서 유효한지 확인하는 방법을 개선하는 것으로, 특정 체인ID가 특정 블록넘버에서 유효한지여부를 알려주는 프리컴파일을 추가한다.

     12> EIP-1702(https://eips.ethereum.org/EIPS/eip-1702)   *최종승인됨(63차 회의)
       - 일반화된 계정버전 관리를 위한 것으로, EVM의 여러버전을 동일한 블록에서 실행할 수있게하여 기존 계정의 정확한 기능을 유지하면서도 HF를 용이하게 한다.

     13> EIP-1706(https://eips.ethereum.org/EIPS/eip-1706)
       - 가스비가 집행비(Call stipend)보다 낮은경우 SSTORE사용을 불가능하게 하자는 제안으로, 이더리움 프로토콜에 긍정적인 효과가 있을수도 있다.

     14> EIP-1803(https://eips.ethereum.org/EIPS/eip-1803)
       - 보다 직관적으로 보이게 하기 위하여 NUMBER, GASLIMIT, GAS 등의 opcode를 각각 BLOCKNUMBER, BLOCKGASLIMIT, GASLEFT 등으로 적절하게 명명한다.

     15> EIP-1829(https://eips.ethereum.org/EIPS/eip-1829)
       - 타원곡선선형조합에 대한 프리컴파일(Precompile for Elliptic Curve Linear Combinations)이다. '이더리움 트랜잭션에 디지털 서명시, 송신자는 그 트랜잭션(거래)에 대한 진위를 수신자에게 확신시킬때 필요한 방정식이 있고, 그것을 사전에 컴파일링하는 방법에 대한 논의'라고 보면 된다.
(자세한 설명은 여기글 후반부를 참조)

     16> EIP-1884(https://github.com/ethereum/EIPs/blob/dcc573e74adc0e6dd25821ddaabf862e8f85e107/EIPS/eip-1884.md)
       - 가스소비와 자원소비 간 균형을 맟추기 위하여 특정 opcode를 제안하며, 적절한 균형은 블록가스제한을 극대화하고 처리시간이 안정화되는 효과가 있다.

     17> EIP-1930(https://eips.ethereum.org/EIPS/eip-1930)
       - 엄격한 가스 의미구조를 지닌 CALL함수 적용 제안으로, 특정 가스량의 CALL을 실행시키는 스마트 컨트렉트를 추가한다. 현재 CALL시행함수들은 전송중인 가스를 시행하지 않고 단순히 가스값을 최대값으로 그대로 간주하는데, 이는 정확한 가스량을 사용하는 어플리케이션에 심각한 문제를 야기할수 있기때문에 개선제안되었다.

     18> EIP-1985(https://eips.ethereum.org/EIPS/eip-1985)
       - 가스제한, 블록넘버 등 EVM 매개변수들에 대한 적정 한계범위를 적용한다. 명시적인 범위를 적용하면 호환가능한 클라이언트를 구현하는데 도움이 된다.

     19> EIP-1959(https://eips.ethereum.org/EIPS/eip-1959)
       - 하나의 체인ID(서로 다른 체인간 트랜잭션 재생을 방지하는 수단)가 체인ID히스토리에 포함되어있는지 확인하는 새로운 opcode를 제안한다. 이는 오프체인 메세지가 다른 체인에서 재사용되지 않도록 보호하기 위함이다.

     20> EIP-1962(https://eips.ethereum.org/EIPS/eip-1962)
       - 타원 산술 및 런타임 정의와 결합에 대한 개선안으로, EIP-1829에 대한 확장안이며 EIP-1109에서의 SATICCAL opcode보다 작업비용이 더 저렴하다.

     21> EIP-2014(https://eips.ethereum.org/EIPS/eip-2014)
       - 확장된 스테이트 오라클이라는 확장가능한 인터페이스를 갖춘 새로운 시스템을 도입하여 체인식별자, 블록해시 등과 같은 확장된 데이터세트에 접근가능하다.

     22> EIP-2026(https://eips.ethereum.org/EIPS/eip-2026)
      - 계정에 대한 고정 선불제(스테이트 렌트B)로, 말그래도 신규계좌를 생선시 고정적으로 일회성 임대료 선불을 부과한다.

     23> EIP-2027(https://eips.ethereum.org/EIPS/eip-2027)
      - 인터넷 컨트렉트규모 계산(스테이트 렌트H)방식이다. 이더리움은 컨트렉트에 채워지거나 비워진 스토리지 슬롯갯수를 계산하는데, 기존의 슬롯갯수가 현재시점으로 계산하지 않기때문에 슬롯갯수의 순수 변화만 효율적으로 추적하는데, 이 개선으로 총 스토리지 슬롯갤수를 추적하게 된다.

     24> EIP-2028(https://eips.ethereum.org/EIPS/eip-2028)
       - Calldata(이더리움 상에서 트랜잭션 요청시 전송 데이트가 저장되는 곳)의 가스비를 현행 바이트 당 68에서 줄인다. Calladata비용이 절감되면 잠재적으로 더 큰 블록이 생겨 네트워크 지연이 증가하지만, 수학적 모델링과 경험적 추정에 의해 네트워크 보안이 강해지고 확장성이 증가되는 부수적인 효과가 있을수도 있다.

     25> EIP-2029(https://eips.ethereum.org/EIPS/eip-2029)
       - 스테이트 카운터 컨트렉트(스테이트 렌트A)도입으로, 다양한 상태 카운터가 저장될수있는 이더리움상의 어떤 장소로 안내한다.

     26> EIP-2031(https://eips.ethereum.org/EIPS/eip-2031)
       - 총 트랜잭션 카운터(스테이트 렌트B)에 대한 개선안으로, 오로지 변경된 트랜잭션수만 알게되는 현재와는 달리 스테이트 내부의 트랜잭션 수를 추척하게 된다.

     27> EIP-2035(https://eips.ethereum.org/EIPS/eip-2035)
       - 블록검증을 위해 SLOAD와 SSTORE실행시 지불해야하는 가격 재책정방식으로, 컨트렉트 스토리지 크기에 따라 비용이 달라진다(가령, 컨트렉트가 작을수록 저렴해진다).

     28> EIP-2046(https://eips.ethereum.org/EIPS/eip-2046)
       - 프리컴파일에 대한 정적호출의 가스비를 줄여, 파일사용이 보다 효율적이게 된다.

     추가> EIP-2024(https://github.com/ethereum/EIPs/pull/2024/files)
       - BLAKE2b라는 새로운 암호화 해싱 알고리듬을 구현하는 사전컴파일 컨트렉트를 EVM에 도입한다.

□ 개인 논평

  ㅇ 이더리움 오케스트라 '이스탄불 협주곡 제2악장'
    - 오케스트라는 관현악 연주를 목적으로 하는 집단적 연주 형태로, 최근의 이더리움 개발자 회의를 보며 하나의 오케스트라와 같다는 생각이 들었다. 각각의 이더리움 핵심개발자들은 다가올 이스탄불HF에 들어갈 EIP에 대해서 검토하고 적용할지에 대하여 논의하여 하나의 목적을 향해 매진하는 모습이, 각자의 악기를 다루며 화음을 만드는 오케스트라 같았다. 따라서 이 연주곡을 다가오는 HF인 '이스탄불'로 표현했고, 2주째 EIP에 대해 논의해서 2악장이라고 표현했다.
    - 물론 그 연주의 화음이 듣기좋을지 불협화음일지는 두고 봐야겠다. 지난 콘스탄티노플HF만 봤듯이 몇개의 EIP를 메인넷에 적용시키는 것이 얼마나 많은 검토, 논의, 테스트 그리고 EIP간 호환성이 필요한지 알 수 있다. 그러한 경험때문에 지금도 EIP를 제안한 개발자들은 열띤 논의를 하고 있는 실정이며, 내년으로 예정된 이더리움2.0의 0단계 이전에 이뤄지는 마지막 네트워크 업그레이드라 더욱 주목된다.

  ㅇ 역사를 잊은 커뮤니티에게 미래는 없다.
    - 앞서 얘기한것은 이더리움만의 내부사정이고, 눈을 외부로 돌리면 시간은 마냥 우리편이 아닌듯하다. 거대 금융사인 JP모건도 그렇고 거대 SNS업체인 페이스북도 그렇고 기존 기득권세력들의 행보가 점점 실체화되고 있어 블록체인 마을 원주민인 비트코인, 이더리움, 리플 등에 어떤 영향을 끼칠지 사뭇 궁금하다. 블록체인과 암호화폐에 대한 활용을 촉진하고 이미지를 향상하는데에는 도움이 되지만 또다시 특정집단이나 카르텔에 의해 대부분의 사용자들이 종속되는 역사가 반복될수도 있다. 이 시점에 우리는 어떻게 해야할까.
    - 우리는 여태까지의 역사를 통해 결국에 기득권의 세계는 항상 공고했으며 결국에 만인은 그들에게 종속될수 없다는 무기력한 학습을 해왔다. 아마도 기존 기득권세력이 블록체인 마을에 다가오는 현재, 그 무기력한 역사의 사슬을 조금이나마 끊을수 있는 시점일수도 있다. 따라서 탈중앙성, 투명성 등 각자 정의하는 것은 다르지만 우리가 옳다고 생각하는 사토시 정신을 기억하고, 그에 걸맞는 프로젝트를 지지하거나 때론 비판하는 등 각자 떨어져있지만 목소리를 내기를 필자는 제언하는 바다. 시간은 더욱 빨리가고 세상도 계속 변하는데 우리만 과거처럼 똑같을수만은 없지 않은가.


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

[Raven] Raven Devs Meeting(7 June 2019) // 6월 7일 레이븐 개발자 회의 분석 및 논평 v1.0

(English) 한국어버전은 아래쪽에 있음

□ Analysis of the meeting by subject



  ㅇ New wallet
    - New Android wallet has been released, which co-exists with Android Classic.
    - Also, the features of the new wallet follow BIP44, and the iOS wallet can be used through 12 recovery words(Mnemonic words).
    - If you have trouble finding your assets with 12 recovery words, it may be because you are using an old Android wallet or an alpha/beta version of iOS wallet. Let me share a guide* and please refer to it.
      * For those who are not familiar with it, let me give you the summary of the guide. 
First, move to https://ravencoin.org/bip44 and then write 12 mnemonic words according to BIP32. The address according to BIP44 is then shown below. The address starts with R, and the assets are available at https://ravencoin.network (for the new address, the balance will be zero, so don't panic). However, in the case of an address with some balance (iOS version in this case), the asset can be utilized through 'personal keyscan' going to 'setup' and 'use a wallet/cain key'. For the QR code, if you move the cursor to the private key next to the address of the webpage, the QR code will be displayed, which can be used when transferring. 

     ※ BIP39 and BIP44
      1) BIP39(https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki)
       This proposal is defined for a list of easy-to-remember words, recovery words(Footnote : usually 
consisting of 12 words, also known as Mnemonic words).
       2) BIP44(https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)
       The proposal defines a design that easily generates more keys in a single seed and induces them easily through a tree structure.

     - In addition, Trust Wallet and Exodus Wallet released today, supporting Ravencoin.

  ㅇ Current status of 'Restricted assets' development
     - Restricted asset coding has been completed and its unit test* is currently underway. Once this unit test is completed, its testnet will be released, including coding of Restricted assets, allowing users to mine blocks and finally vote on Restricted assets. Afterwards, once the voting is successfully tested and activated, it will only be available on testnet. Under the current deployment, there will be no QT/GUI** support, but it will be completely at the RPC level***. On its testnet, we can expect its release in QT/GUI. Personally, I hope that the community is ready for great new features about assets.

      * Unit test : It bundles up codes that exist individually in a specific module or application to ensure that they work as expected, better understand detailed codes, and easily test.
      ** QT/GUI: Cross-platform or software development kit for GUI in computer programming area
      *** Remote Procedure Call (RPC) : It is a communication technology that enables different functions (procedures) to be performed using the same code in separate spaces, also known as Remote Invocation.

      - 'Messaging' will be included in the development of Restricted assets. In fact, the core protocol for memo and messaging (Footnote : the fundamental communication protocol) is already being tested on testnet In addition, once QT/GUI is built for restricted assets, the next step will be to develop Voting, and hard-fork will be happened when the function is deployed on mainnet. 

  ㅇ InterPlanetary File System (IPFS) Issue
    - First of all, let me summarize the concept of IPFS before addressing devs' discussion of IPFS. IPFS is a method of storing (or recording) data in blockchain. This is a method of decentralizing or distributing data, which has kinda the same principle as a torrent. This is much more important for Raven platform that deals with legal documents, corporate information and so on because block size, whether Bitcoin or Raven, is only 1MB (realistic reasons), and data cannot be stored or exchanged whenever there is a problem with 
the central server, and there are monopolistic phenomena of organizers who own the central server (reason for risk management).
     - (Back to devs meeting) The combination with messaging and IPFS will be proceeded as soon as possible and we will try to complete the combination on the QT/GUI before restricted asset is deployed on mainnet.   

  ㅇ European Meetup
    - If you are interested in European Meetup, please attend Raven Meetup in Amsterdam on June 19. 


□ Personal Comment

  ㅇ Personal secret investigation as a fundamental analyst
    - I explore the devs meeting with the feeling that I enter into a cave loaded with beasts holding a rod, as I can mostly feel the joy of having knowledge and achievement more than the burden. Even in this meeting, such excitement remains the same, but as I summarize it, I suddenly remember an episode.
     - I have watched and analyzed Ethereum devs meeting regularly since 2017, and I sometimes really focus on it ahead of big events like hardforks or big volatility (whether rising or falling) in the market. In such sensitive situations, it is not easy to fully enjoy devs meeting things(It is true, you give it a try).
     - I personally call it 'Secret investigation' when analyzing devs meeting with exceptional concentration. Thanks to the investigation, I could enjoy the rise of Ether in 2017 and also find some reasons when its price fell continuosly in 2018. 

  ㅇ Refrain from rosy expectation in secret investigation
    - What I am doing right now is 'Raven investigation in secret'. Its interesting thing is that 
it evokes nostalgia for existing highly potential projects like Ethereum, EOS or Cosmos.
     - Apart from these expectations, Raven has a very long way to go. Even simple functions, not complicated, are now being tested on testnets rather than on mainnets, and because of its abscence of specific ownwer, the develepment speed of the project is a bit slow from a business perspective. In a way, the presence of Patrick Byrne of Overstock, which is widely known in connection with Raven, may sometimes be appreciated.
    - But even 'The Creation' painting was begun with light bruch touches by Michelangelo, the promising project, Raven, will probably be a masterpiece too like the painting. Anyway, my personal secret investigation in Raven continues today.



(한국어)

□ 소재별 회의 내용

  ㅇ 새 지갑 출시
    - 새로운 안드로이드 지갑이 출시되었고, 이 지갑은 이전 안드로이드 지갑(안드로이드 클래식)과 공존(co-exist)한다.
    - 또한 새로운 지갑의 특징은, BIP44를 따르며, 12개 복구 단어(니모닉, Mnemonic words)를 통해 iOS지갑을 사용할수 있다.
    - 누군가 12개 복구 단어로 자산을 찾는데 어려움이 있다면 이전 안드로이드 지갑을 사용하고 있거나 알파/베타 버전의 iOS지갑을 사용하고 있기 때문일것이다. 이럴때는 안내글*을 작성했으니 참고바란다.
      * 귀차니스트를 위하여 안내글을 요약하여 안내한다. 우선 https://ravencoin.org/bip44로 이동한다. 그리고 BIP32에 따라 니모닉 12단어를 입력한다. 그러면 BIP44에 따른 주소가 아래에 나타난다. 그 주소는 R로 시작하며, 자산은 https://ravencoin.network에서 조회 가능하다(새로운 주소의 경우, 잔액이 0일테니 당황하지 말것). 다만, 잔액이 있는 주소의 경우(여기선 iOS에 한함), '설정'에서 '지갑/캐인키사용'으로 이동한 뒤, '개인키스캔'을 통해 자산을 활용가능하다. QR코드 사용의 경우, 웹페이지 주소 옆 개인키로 커서를 이동하면 QR코드가 나오는데 송금시 활용가능하다. 

     ※ BIP39와 BIP44
      1) BIP39(https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki)
       이 제안은, 기억하기 쉬운 단어 목록인 복구 단어(필자주: 보통 12개의 단어로 구성되며, 니모닉코드(Mnemonic code)라고도 한다)에 대하여 정의한 내용이다.
       2) BIP44(https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)
       이 제안은, 하나의 시드에서 더 많은 키들을 쉽게 생성하고 트리구조를 통해 쉽게 유도하는 설계를 정의한 내용이다.
     - 또한, Trust Wallet과 Exodus Wallet 역시 레이븐코인을 지원하며 오늘 출시되었다.

  ㅇ 제한자산(Restricted assets) 개발 현황
     - 현재 제한자산 코딩은 완료되었으며, 현재 유닛 테스트*중이다. 이 유닛 테스트가 완료되면, 제한자산 코딩을 포함한 새로운 테스트넷을 출시할것이며, 사용자들은 블록을 채굴하고 제한자산에 투표할 수 있을것이다. 이후, 성공적으로 투표가 이뤄지고 활성화되면, 비로소 테스트넷 상에서 제한자산을 사용할 수 있을것이다. 우리가 출시하려는 현재의 구축상으로는, QT/GUI**에 의한 지원은 없을거지만, RPC수준***에서는 완전히 작동될것이다. 테스트넷에서의 테스트를 하면서, 제한자산 기능이 점차 포함될 QT/GUI상에서의 출시도 기대할수 있을것이다. 개인적으로 (제한)자산에 대한 새로운 멋진 기능들에 대해 커뮤니티가 (즐길) 준비가 되어있길 바란다.
      * 유닛테스트(Unit test) : 특정 모듈 또는 어플리케이션 상 개별적으로 존재하는 단위(unit) 수준의 코드를 묶어서 처리하되 예상대로 잘 작동하는지 확인하는 것으로, 작동여부 확인 외에도 세부적인 코드를 더 잘 이해하고 향후 있을 테스트를 더 쉽게 하는 효과도 있음(필자주).
      ** QT/GUI : 컴퓨터 프로그래밍 분야에서 GUI(그래픽 유저 인터페이스)개발에 활용되는 상호호환 소프트웨어 개발도구(Cross-platfrom softward developmen)로 누구나 무료로 사용할수 있는 오픈소스 개발도구이기도 함.
     *** RPC(Remote Procedure Call, 원격 프로시저 호출) : 이름에서 유추되듯이, 서로 떨어져있는 공간에서 동일한 코드를 활용하여 다양한 함수(절차) 등을 실행하게 해주는 통신기술로서, Remote Invocation(원격호출)이라고도 함.
      - 참고로 메시징(Messaging) 기능은 제한자산 개발에 포함될것이다. 실제로 메모(Memo)와 메시징을 위한 코어 프로토콜(필자주 : 근간이 되는 핵심 통신규약)은 이미 테스트넷에 테스트 중이다. 또한, 제한자산을 위한 QT/GUI가 구축되고나면 다음 단계는 투표(Voting)기능 개발이 될것이며, 투표기능을 메인넷에 올릴때에는 하드포크가 수반된다. 

  ㅇ IPFS(InterPlanetary File System) 이슈
    - 우선 IPFS에 대한 개발자의 논의를 다루기 전에 IPFS에 대한 개념을 정리해보자. IPFS는 블록체인에 데이터를 저장(또는 기록)하는 방식이다. 이는 데이터의 탈중앙화 또는 분산하는 방식으로, 편의상 비유하자면 토렌트와 같은 원리를 지닌다. 사실 비트코인이든 레이븐이든 블록크기가 1MB에 불과하기도 하고(현실적 이유), 중앙서버에 문제가 생길때마다 데이터를 저장하지 못하거나 주고받지 못하는 문제, 그리고 중앙서버를 소유한 주최측의 독과점 현상(리스크관리 이유)도 있기때문에, 법적 문서, 기업 정보 등이 저장될 레이븐 플랫폼에게는 더욱 중요한 요소라고 볼수 있다.
     - (개발자 논의로 다시 돌아와서) 메시징 등과 같은 기능과 IPFS와의 결합은 가능한 빨리 추진할것이며, 시기적으로는 제한자산이 메인넷에 올려지기 전에 QT/GUI상에서 결합을 완료하도록 노력할 것이다.   

  ㅇ 유럽 밋업
    - 유럽 밋업에 관심있다면, 6월 19일에 암스테르담에서 레이븐 밋업이 있으니 참석바란다. 


□ 개인 논평

  ㅇ 기본적 분석가의 뒷조사
    - 필자는 늘상 부담을 느끼면서도 그 부담 이상의 지식과 성취감을 맛볼수 있기에, 나무 막대기 하나 들고 맹수가 우글거릴 동굴을 들어가는 기분으로 개발자 회의를 탐험한다. 이번 개발자 회의때도 그런 짜릿한 마음은 변함없지만 정리하다보니 문득 에피소드 하나가 생각이 난다.
     - 레이븐 개발자 회의 외에 정기적으로 정리하는 이더리움 개발자 회의는 2017년부터 현재까지 꾸준히 들어오고 있지만 유난히 집중해서 들을때가 있다, 바로 하드포크같은 큰 이벤트를 앞두거나 시세에 큰 변동성(상승이든 하락이든)이 존재할때다. 사실 그러한 예민한 상황에 외계어들이 난무하는 개발자 회의를 라이브로 들으면서 관련 깃헙을 동시에 읽고 정리하는 것은 매번 정말 어려운 작업이다. (정말이다, 한번 해보시라ㅠ).
     - 여튼 유난히 집중해서 개발자 회의를 듣고 분석하는 것을 필자는 '뒷조사(Secret investigation)'라고 자칭한다. 그 뒷조사 덕분에 이더가 떡상할때도 팔지않는데 일조를 했고, 2018년 끝없는 하락에도 왜 하락하는지 몇몇 단서를 파악할수 있었다. 

  ㅇ 뒷조사의 희망적 예단은 금물
    - 지금 필자가 하고 있는 것은 '레이븐 뒷조사'다. 이 조사가 기본적 분석가로서 재미있는 부분은, 기존의 매우 잠재력있는 프로젝트의 향수를 불러일으킨다는 것이다. 이더리움을 처음 알았을때, 이오스 백서를 처음 볼때, 코스모스 관련 기사와 재권의 인터뷰를 볼때와 유사한 느낌이다.
     - 다만, 이러한 기대와는 별개로 레이븐이 갈길은 매우 멀다. 복잡한 기능은 커녕 단순해 보이는 기능조차 메인넷이 아닌 테스트넷에 이제 테스트중이며 특정주최가 없는 특성상 영업 측면에서 볼때 가시적인 성과를 내는 속도가 상대적으로 느릴수밖에 없다. 솔직히 투자자로서는 레이븐과 연관되어 공공연히 거론되는 오버스탁(Overstock)의 패트릭번(Patrick Byrne)의 존재가 가끔은 고맙게 느껴질수도 있다.
    - 하지만 희대의 예술가 미켈란젤로가 그린 천지창조도 처음에는 가벼운 붓터치로 시작했듯이, 과연 잠재력있는 레이븐 프로젝트가 사용자는 물론 일반인들을 압도하는 명작이 될지 내심 궁금하다. 그런의미에서 오늘도 필자의 뒷조사는 계속된다. 


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


[Poem] '가치'라는 이름(원작 : 김춘수의 '꽃') v1.0

< https://weheartit.com/entry/310889216 >


'가치'라는 이름

코인시인 오공


그가 나의 이름을 불러주기 전에는나는 다만 한명의 '잠재력있는 개체'에 지나지 않았다.

그가 나의 이름을 불러주었을 때,
나는 세상앞에 나와 '가치있는 주체'가 되었다.

그가 나의 이름을 불러준 것처럼
나도 누군가에게 
그 열정에 알맞는 이름을 불러주고 싶다.

그(녀)에게로 가서 나도
그(녀)의 '가치있는 존재'가 되고 싶다.

우리들은 모두
블록체인 커뮤니티의 그 누군가가 되고 싶다.

너는 나에게 나는 너에게
암호화폐 영역에서의 
'의미있는 가치'가 되고 싶다. 



<작품설명>
지난 5월에는 개인적으로 정말 힘든 일을 겪었습니다. 코인 분석과 투자조차도 당장 그만둘정도로 심각했지만, 천만다행으로 2가지 큰 깨달음이 저를 일으켜 세웠습니다.
첫째는, 힘들어서 코인 분석과 투자를 그만둘것 같았지만 그 와중에 독서, 상념, 그리고 기고활동을 꾸역꾸역 이어가는 스스로를 보며 '이 길이 진정 내 길'이라는 생각이 들었습니다.
둘째는, 그간 이더리움 개발자 회의 분석 및 논평 글 등을 통해 이더리움을 알린 공로로 Ethereum Foundation(이더리운 재단)측의 초청으로 참석한 '이드콘 2019 코리아 시상식'(관련기사 디센터, 코인데스크크리아 클릭)에서 공로상 수상과 함께, 비탈릭의 축사영상에 제가 언급(영상 여기 클릭, 2분25초에 살짝 언급)되었고 댓가를 바라지 않은 일에도 어떤 형태로든 보상이 있을수 있고 그 보상이 또다른 행위의 발판이 될수도 있다는 생각이 들었습니다.

여전히 힘든 사건에 따른 상처는 다 아물지 않았지만, 앞서 언급한 내/외적 깨달음을 통해 저 스스로의 존재가치를 파악할수 있었고 바로 그때 김춘수의 '꽃'이 떠올라 패러디 해봤습니다(패러디 시 속의 '그'는 '비탈릭'일수도, 제 안의 '또다른 저'일수도, 아니면 절 응원하는 '여러분 중 한명'일수도 있습니다).

이 글을 빌어, 저를 응원하시고 제 글을 봐주시는 여러분과 저 스스로에게 더욱 더 '가치있는 주체'가 되기를 다시 한번 다짐하겠습니다(참고로 저는 제가 기고하는 모든 커뮤니티들에서 제 글에 추천과 댓글 주시는 분들 뿐만 아니라, 코인 관련해서 만나거나 연락한 거의 모든 분들을 기억하고 있습니다).

※ 본문의 시와 글을 Ethereum Foundation 관계자인 TY님에게 헌정합니다.

원작 "꽃"

김춘수

내가 그의 이름을 불러주기 전에는
그는 다만 하나의 몸짓에 지나지 않았다.

내가 그의 이름을 불러주었을 때,
그는 나에게로 와서 꽃이 되었다.

내가 그의 이름을 불러준 것처럼
나의 이 빛깔과 향기에 알맞는
누가 나의 이름을 불러다오.

그에게로 가서 나도 
그의 꽃이 되고 싶다.

우리들은 모두
무엇이 되고 싶다.

너는 나에게 나는 너에게
잊혀지지 않는 
하나의 눈짓이 되고 싶다.

[Raven] Raven Devs Meeting(31 May 2019) // 5월 31일 레이븐 개발자 회의 분석 및 논평 v1.1


(English) 한국어 버전은 아래쪽에 있음

□ Analysis of the meeting by subject

  ㅇ Tags and Restricted Assets Development Status
    - Currently, some developers are focusing on developing tags and restricted assets. I hope to get a goo result and I will go through a lot of testing, and there will be a lot of changes.
    - The developers will share the development status of tags and restricted assets posted on Github, discuss and improve them through reviews and comments.
    - In addition, some developers said they were using Qt* for the development and testing of tags and restricted assets and hoped for some progress.
     *Qt : Cross-platform or software development kit for GUI in computer programming area

    - Initial development of tags and restricted assets will take about one to two weeks at Qt and will then be posted on testnet.

  ㅇ Mobile Wallet and Mnemonic
    - Let me say its relevant background information first. As cryptocurrency wallet technology advances, more usable and more broadly compatible industrial standards appear, some of which are two wallet standards by Bitcoin Implementation Proposals(BIP).
    - First of all, it is about BIP-39. This proposal is defined for a list of some words to create a deterministic wallet*, which is often comprised of 12 to 24 words, or mnemonic code.
     *Deterministic/Non-deterministic wallet : It is divided into two kinds of wallets, depending on how to produce keys. Non-deterministic/Random wallets are mutually independent because all keys are generated from different random numbers. A good example is Ethereum Wallet, which is somewhat inconvenient in terms of management, as a single wallet file(e.g., JSON encoding file) is created according to a randomly generated individual key. On the other hand, 'Deterministic/Seeded' wallets are complementary because every key is generated from a single seed(Master key concept). A good example is Raven mobile wallet, which is relatively simple to manage and use, as you can always recover your wallet with only 12 words.
< Deterministic(Left) and Non-deterministic wallet(Right)(https://potensj.tistory.com) >

    - Next, it is about BIP-44. The proposal is designed to create 'Hierarchical Deterministic' wallets, more advanced ones. They are designed to easily generate many keys from a single seed and lead easily through a tree structure. In addition, this hierarchical critical wallets are a very useful mechanism for generating keys hierarchically from the initial seed, protecting personal information in transactions such as generating new addresses every time a transaction occurs, making it difficult to hack, and managing the wallets(address) derived from numerous keys.
< 'Hierarchical Deterministic' wallets(https://potensj.tistory.com) >

    - Back to the devs meeting. Tron said we need to discuss the mnemonic code in mobile wallets. This issue involves the implementation of synchronization(Footnote : sync, process of scanning a blockchain to find assets in a wallet) such as reinstalling a wallet and connecting to a network for the first time in a long time. When synchronizing, we proposed to add 'optional' information, such as 'number of days after Bitcoin Genesis block generation on 3 January 2009. It means specific weeks after bitcoin Genesis block generation. For example, 10 weeks can be replaced with 10 when we replace the Genesis block generation week with 0.
< How to create mnemonic from entropy and SHA256(https://potensj.tistory.com) >

    - The photo just above shows the process of creating mnemonic code(12 words in this case) from 132 bits combined with a checksum 4 bit extracted from SHA256.
    - Back to the devs meeing, Tron proposed using some of the 128 bits generated(to create mnemonic, etc) as a number instead of entropy. For example, 1) 96 bits of the existing 128 bits will be remained as entropy and the remaining 32 bits will be time stamp*, or 2) 128 bits will be entropy as previously used, but certain numbers(i.e., certain weeks after the Genesis block) will be used to speed up blockchain scan and sync. In the first case, 32 bits are used as a time stamp, disadvantageous from security side, and in the second case, it is a bit inconvenient to fill out a specific number in the existing method."
     * Timestamp : In the real world, the time is expressed as 00:00:00 but in the digital world, unique time record system exists, such as Unix time. Bitcoin also records time based on transaction occurrence time. The timestamp configuration at 32 bits as mentioned by Tron is to include this Unix time so that it can be set to work from the specific block generation criteria when scanning and synchronizing blockchain.
    - Although the proposal for fast blockchain scan and synchronization operation of Tron was echoed by other devs, some said that the GUI method(Footnote : moving the synchronization starting block by using mouse or typing the number) was more intuitive than the method proposed by Tron, and others agreed with it.

  ㅇ Current status of messaging, dividends, and voting development
    - Development of messaging has been almost completed, and its development and testing schedules are the same as restricted assets. As mentioned before, messaging and restricted assets are currently being built using Qt.
    - We have some devs who develop dividends now, but can't check what is going on because they are not in the devs meeting. Others who develop dividends will join us at the next meeting.
    - The development of voting will come in the next step after restricted assets are deployed on testnet.

  ㅇ When official Raven roadmap published
    - It could be christmas gift, hoping to be completed by the end of 2019.


□ Personal Comment

  ㅇ Stability and Convenience
    - Through this developer conference, we learned more about the mechanism of Raven's wallet, as well as thinking about network stability and user convenience.
    - The current status of Raven's wallet development is to achieve user convenience at minimum of changes saving network stability.
    - At the same time, the devs are working on various functions such as tags, restricted assets, messaging, dividends and voting.

  ㅇ The way it's been through and the way it will go through
    - This open-source project, which may be nothing, has been developed and improved by volunteer wokers as they get together for the same vision and goals.
    - The 'potential' has been transformed to 'value' based on volunteers and its community and it still continues.
    - Some say 'overlapping of the pasts is the present.' Whether the overapping is inevitable or accidental, the important thing is that the future of Raven, which we are interested in and participating in, will also be the overlapping of our current paths. In this sense, we hope that we, Raven supporters, enjoy ourselves in our own way and see how Raven draws its future.



(한국어)

□ 소재별 회의 내용

  ㅇ 태그(Tags)와 제한자산(Resticted Assets) 개발 현황
    - 현재 일부 개발자들이 태그와 제한자산의 개발에 매진하고 있다. 좋은 방향으로 추진되기를 바라며, 많은 테스트과정을 거칠것이고, 자연스럽게 많은 변화가 있을것이다.
    - 해당 개발자들이 깃헙(Github)에 올린 태그 및 제한자산에 대한 개발현황을 공유하고, 리뷰 및 코멘트를 통해 논의 및 개선할 것이다.
    - 또한 해당 개발자들은 태그와 제한자산의 개발과 테스트를 위하여 Qt*를 활용하고 있으며 진전이 있길 바란다고 말했다.
     *Qt : 컴퓨터 프로그래밍 분야에서 GUI(그래픽 유저 인터페이스)개발에 활용되는 상호호환 소프트웨어 개발도구(Cross-platfrom softward developmen)로 누구나 무료로 사용할수 있는 오픈소스 개발도구이기도 함.
    - 전반적으로 태그와 제한자산에 대한 초기 개발은 Qt에서 1-2주정도 소요될 예정이며, 이후 테스트넷에 올려질것이다.

  ㅇ 모바일 지갑과 복구 암호(니모닉)
    - 우선 개발자들이 논의한 내용을 살펴보기 이전에 관련 배경지식에 대해 알아보자. 암호화폐 지갑기술이 발전하면서 보다 사용하기 편하고 보다 폭넓게 호환가능한 산업표준들이 등장하였고, 여기서는 본 개발자 회의에서 언급된 것이면서, 비트코인개선제안(Bitcoin Improvement Proposals, BIP)에 의한 지갑표준 2가지에 대해 알아보겠다.
    - 우선 BIP-39관련이다. 이 제안은, 결정론적 지갑*을 만들기 위해 기억하기 쉬운 단어 목록인 복구암호(필자주: 보통 12~24개의 단어로 구성되며, 니모닉코드(Mnemonic code)라고도 한다)에 대하여 정의한 내용이다.
     *결정적-비결정론적 지갑 : 지갑을 구분할때 생성된 키들간의 관계에 따라 결정적 지갑과 비결정적 지갑으로 나뉜다. '비결정적(Non-deterministic/Random) 지갑'은 모든 키들이 서로 다른 난수로부터 생성되므로 상호 독립적이다. 대표적인 예로 이더리움 지갑이 있으며, 랜덤으로 생성된 한 개인키에 따른 지갑파일(예: JSON인코딩파일)이 하나 만들어지는데 각 키에 따라 별도의 지갑이 존재하므로 관리와 사용면에서 다소 불편하고 번거롭다. 반면, '결정적(Deterministic/Seeded) 지갑'은 하나의 모든 키들이 하나의 시드(마스터키 개념)로부터 생성되므로 상호 보완적이다. 대표적인 예로 레이븐 모바일 지갑이 있으며, 12개의 단어만 알면 언제든 본인 지갑 복구가 가능하므로, 관리와 사용면에서 상대적으로 간편하다.

    - 다음으로 BIP-44관련이다. 이 제안은, 결정론적 지갑보다 한차원 진보한 '계층 결정적(Hierarchical Deterministice)' 지갑을 만들기 위한 것으로, 하나의 시드에서 더 많은 키들을 쉽게 생성하고, 트리구조를 통해 쉽게 유도하는 설계를 정의한 내용이다. 또한, 이 계층 결정적 지갑은 최초 시드로부터 계층적으로 키를 생성하는데 거래가 발생할때마다 새로운 주소를 생성하여 해킹을 어렵게 하는 등 거래 또는 조회시 개인정보를 보호하며, 수많은 키와 그로부터 파생되는 지갑(주소)를 관리하는데 매우 유용한 메커니즘이다.
< 계층 결정적 지갑 도식화(https://potensj.tistory.com) >

    - 그러면 다시 개발자 회의로 돌아가 보자. 트론은 모바일 지갑에서의 니모닉 코드에 대한 논의가 필요하다고 말했다. 이 사안은 지갑 재설치, 오랜만에 네트워크 접속 등 동기화(Sync, 블록체인을 조회하여 지갑 내 자산을 찾는 일련의 과정)를 실행하는 것과 관련된 사안이다. 동기화할때, 특정 블록으로부터 동기화를 하게 하여 시간을 절약할수 있도록 숫자(필자주: 여기서 숫자는 2009년 1월 3일 비트코인 제네시스 블록생성 이후의 기간중 특정 주간을 의미하는 것으로, 가령 제네시스 블록생성 주간을 0으로 치환하면 10주후 주간은 10으로 치환할수 있음)와 같은 '선택적인(optional) 추가정보'를 포함시키자고 제안하였다.
< 엔트로피 및 SHA256으로부터의 니모닉 생성과정(https://potensj.tistory.com) >

    - 바로 위 사진은 128비트 엔트로피와 SHA256으로부터 추출된 체크섬 4비트가 결합된 132비트로부터의 니모닉(여기선 12개 단어) 생성 과정을 보여주고 있다. 바로 뒤의 내용이 어려울것 같아 잠시 언급해봤다.
    - 다시 개발자회의로 돌아와서, 트론은 (니모닉 등을 생성하기 위해) 생성된 128비트 중 일부를 엔트로피(필자주 : 무작위 수준을 결정하는 것) 대신 숫자로 사용하자는 것을 제안하였다. 가령, 1)기존의 128비트 중 96비트는 엔트로피로 남기고 나머지 32비트는 타임스탬프*로 구성하거나 아니면 2)기존대로 128비트를 엔트로피로 하되 특정 숫자(즉, 제네시스 블록생성 이후 특정 주간)를 사용케 하여 블록체인 조회 및 동기화 작업이 빨라질수 있을 것이다. 1번의 경우, 32비트가 타임스탬프로 활용되므로 시드 보안측면에서는 불리할수 있고, 2번의 경우, 기존 방식에 별도의 특정 숫자를 기입하는 약간의 번거로움이 있다고 말했다.
     * 타임스탬프(Timestamp) : 시간을 기록하는 의미로, 현실세계에서는 0월 0일 0시 0분으로 표현하지만 디지털세계에서는 유닉스타임(Unix time) 등 그 세계만의 고유한 시간기록체계가 존재하며, 가령 비트코인은 거래발생시간을 기준으로 시간을 기록하고 있음. 트론이 말한 32비트에서의 타임스탬프 구성은 이 유닉스타임을 포함시켜 블록체인 조회 및 동기화 작업시 특정 블록생성 기준부터 작업을 하게끔 설정하기 위함
    - 트론의 빠른 블록체인 조회 및 동기화 작업방식 제안은 다른 개발자들의 공감을 샀으나 일부 개발자는 코딩으로 숫자를 포함하여 동기화 시작 블록을 고르는 방식말고, 보다 직관적으로 GUI방식(필자주: 동기화 개시 블록을 마우스로 이동하여 클릭한다던지 숫자를 타이핑하는 방식)을 도입하자고 말했고 다른 개발자도 트론이 제안한 방식보다 더 간편하다고 말하며 공감하였다.

  ㅇ 메시징(Messaging), 배당(Dividens), 투표(Voting) 개발 현황
    - 메시징에 대한 개발은 대략 완료되었고, 개발 및 테스트 일정은 제한자산과 같으며, 앞서 언급했듯이 현재 Qt를 활용하여 메시징과 제한자산을 구축중이라고 말했다.
    - 배당에 대한 개발은 추진중인 개발자가 있으나 개발자회의에 불참하고 연락이 닿지 않아 확인할수 없으며, 배당 개발을 하고 있는 다른 개발자들이 있으니 알아보고 다음 회의때 공유하겠다.
    - 투표에 대한 개발은 앞서 언급된 제한자산 등이 테스트넷에 올려지고 난 다음 단계에 다룰 예정이다.

  ㅇ 레이븐 공식 로드맵 공개
    - 2019년 말까지 작성 완료되길 바라며 크리스마스 선물이 될수도 있다.


□ 개인 논평

  ㅇ 안정성과 편의성
    - 이번 개발자 회의를 통해서 레이븐 지갑의 메커니즘에 대해 좀 더 알게 되었고, 더불어 네트워크 안정성사용자 편의성 역시 생각하는 계기가 되었다.
    - 현재 레이븐의 지갑 개발 현황은, 네트워크 안정성을 해치지 않는 범위내에서 최소한의 변경을 하여 최대한의 사용자 편의성을 달성하려고 한다.
    - 물론 그와 동시에 태그, 제한자산, 메시징, 배당, 투표 등 다양한 기능을 개발하고 구현하기 위해 노력하고 있다.

  ㅇ 걸어온 길과 걸어갈 길
    - 아무것도 아닐수도 있는 이 오픈소스 프로젝트에, 서로 다른 길을 걸어왔고 서로 다른 능력을 가진이 이들이 모여, 서로 같거나 상호 보완이 가능한 비전과 목표를 향하고 있다.
    - 여기서 발현된 '잠재가능성'은 점점 더 많은 이들의 관심과 참여가 모여 어느순간 '가치'가 발생하였고 현재까지 이어지고 있다.
    - 혹자는 '과거들의 중첩이 현재'라고 말한다. 그 중첩이 필연적인지 우연적인지 모르겠지만 중요한 것은 우리가 관심을 갖고 참여하는 '레이븐의 미래 역시 현재 우리가 걸어가는 길들의 중첩이 될것'이라는 점이다. 그런 의미에서 현재 레이븐을 지지하하는 우리 역시 나름대로의 방법으로 즐기면서 레이븐이 어떤 모습으로 중첩되어 미래를 그려나갈지 기대해보자.

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

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