[Article] Vitalik Buterin: Increasing Transaction Costs Risk Limiting Ethereum Adoption // 비탈릭 부테린: 트랜잭션 비용 증가는 이더리움 채택에 제한을 걸다

Vitalik Buterin: Increasing Transaction Costs Risk Limiting Ethereum Adoption 비탈릭 부테린: 트랜잭션 비용 증가는 이더리움 채택에 제한을 걸다


□ Article contents(기사내용)

The increased cost of transacting on the ethereum blockchain is hurting the software’s adoption, says project creator Vitalik Buterin.
프로젝트 제작자 비탈릭 부테린은 이더리움 블록체인에서의 거래 비용이 증가하면서, 이 소프트웨어의 채택에 타격을 입히고 있다고 말한다.

Speaking with the Toronto Star this week, Buterin suggested projects that are considering whether to build on the technology will likely be butted out as the blockchain is overloaded with transactions, or in his words “almost full.”
(While a blockchain cannot ever be technically ‘full,’ Buterin’s comments indicate his current sentiment on the severity of the problem.)
부테린은 이번 주 토론토 스타와의 인터뷰에서, 이더리움 블록체인이 트랜잭션으로 꽉 차있거나 거의 꽉차있다는 이유로, 이더리움을 기반으로 구축할지 고려중인 프로젝트들은 존폐의 기로에 서게 될 수 있다고 말했다.
(블록체인은 기술적으로 꽉 찰수는 없지만 부테린의 발언은 문제의 심각성에 대한 그의 현재 감정을 보여준다.)

Still, Buterin’s comments speak to his understanding of the difficulties ahead for the project, with major planned upgrades including Ethereum 2.0 and a switch to proof-of-stake consensus ahead.
그러나 부테린의 발언은, 이더리움2.0을 포함한 계획된 주요 업그레이드와 향후 지분증명합의로 전환과 함께 이 프로젝트가 마주할 어려움을 반영하고 있다.

He told the newspaper:
“If you’re a bigger organization, the calculus is that if we join, it will not only be more full but we will be competing with everyone for transaction space. It’s already expensive and it will be even five times more expensive because of us. There is pressure keeping people from joining, but improvements in scalability can do a lot in improving that.”
그는 신문사의 인터뷰에서 이렇게 말했다.
"큰 기관이 들어올때, 그들은 이더리움 네트워크에 합류시 더 꽉 찰 뿐만 아니라 거래 공간을 놓고 모든 참여자들과 경쟁할거라고 생각할겁니다. 그렇지 않아도 이미 수수료가 높은데, 합류하면 우리때문에 심지어 5배 높을것이다. 이는 합류하는 것을 주저하게 만들고, 따라서 확장성 개선은 그런 문제 역시 개선시킬것이다.

Ethereum’s seven-day transaction fee average, a measure of demand on the network, actually sits at a 50-day low, falling since July 1 to sit around $0.11 ether per transaction currently.
이더리움의 주간 거래 수수료 평균은, 네트워크 수요의 척도로써, 실제로 7월 1일 이후 50일 동안 최저 수준으로, 현재 거래당 $0.11에 머물고 있다.

Ethereum’s seven day mean transaction fee image via Coinmetrics
Coinmetrics를 통한 이더리움의 주간 평균 거래 수수료 이미지

Buterin, following past arguments and his current work, presented PoS as a potential solution to the problem, stating that altering transaction verification could lower fees by a factor of 100 per transaction, freeing space for organizations to build on the blockchain.
부테린은 과거의 주장과 그의 현재 작업에 이어, PoS를 잠재적인 해결책으로 제시하면서, 거래 검증을 변경하면 거래당 수수료를 100배까지 낮출 수 있으며, 집입 기관들이 블록체인에 구축할 공간을 확보할 수 있을거라고 말했다.

More broadly, the comments show how public adoption of ethereum is a growing concern. Earlier this month, the Enterprise Ethereum Alliance (EEA) appointed the Ethereum Foundation’s Aya Miyaguchi head of its Mainnet Initiative, a working group to connect enterprises with ethereum’s services.
넓게 보면, 그의 발언은 이더리움의 대중적 수용이 얼마나 큰 관심거리인지를 보여준다. 이달 초 이더리움기업연합(EEA)은 이더리움 재단의 미야구치 아야를 메인넷 이니셔티브 대표로 임명했다.

Discussing governance and adoption, Buterin said price volatility and cybersecurity remain leading issues as well. He concluded that the government has a role in regulating the space:
부테린은 거버넌스와 채택을 논의하면서, 가격 변동성과 사이버 보안도 여전히 중요한 이슈라고 말했다. 또한, 그는 정부가 공간을 규제하는데 큰 역할을 한다고 결론지었다.

“Governments do have a role and one of the roles in regulation. The usual concerns are about cryptocurrency exchanges where the basic idea is to do fundraising for a new project by directly selling tokens on the blockchains. There are debates whether specific kinds of ICOs [initial coin offerings] are legally categorized as securities.”
"정부의 역할 중 하나는 규제를 하는 것이며, 블록체인상에서 토큰을 직접 판매함으로써 새로운 프로젝트를 위해 자금조달을 하는 암호화폐 거래소에 대한 우려가 크다. ICO의 일부를 법적으로 증권으로 분류하는지에 대한 논란이 있다.

Buterin pointed toward low-risk uses of blockchain, such as identification of certifications, as adoption-leading technology.
아울러 부테린은 채택 선도 기술로써 인증 확인과 같은 위험부담 적은 블록체인 활용방안에 대해서도 언급했다.

□ Personal Comment(개인 논평)

  - 부테린 군이, 예전엔 단기 확장성 솔루션으로 영지식증명을 활용한다고 했다가 지난 7월에는 비트코인캐시 체인이나 이더리움 클래식 체인을 활용하자는 아이디어*를 낸걸 보고있자면, 이더리움 확장성 해소가 그만큼 시급하고 중요하다고 할것이다.
 ※ 관련글: https://ethresear.ch/t/bitcoin-cash-a-short-term-data-availability-layer-for-ethereum/5735
  - 여튼 기사내용 중, 부테린 군이 이더리움 체인이 현재 과부하 상태라 새로운 기관들이나 프로젝트들이 진입하기 어렵다고 지적하였고, 특히 이더리움 거래량이 거의 다 찼다고 말할정도로 현재 상황이 가볍지 않다는 뉘앙스를 풍겼다. 이 상황을 반전시킬수 있는 모멘텀은 아무래도 저 역시 최근 글들을 통해 강조한 '이더리움2.0'일것이다. 
  - 그런 관점에서 저 기사를 보며 저는 2가지를 생각했습니다. 첫째로, (기사에서 PoS도입시 거래당 수수료가 100배 저렴해질거라고 했는데 왜 100배인지는 전 아직 모르겠지만) 유효성 검증과 투표, 그리고 거래처리속도가 왜 빨라지느냐에 대한 것이다. 우선 현재 이더리움 설계상으로는 벨리데이터(유효성 검증자)가 투표(검증자가 올바르다고 생각하는 블록에 메시징)마다 거래내역을 제출해야하기때문에 부하가 걸리고 결국 병목현상이 일상이 되는 등 체인의 확장성에 한계를 보여줬다. 그런데 이더리움2.0 설계상에서는 PoS메커니즘을 총괄하는 비콘체인 덕분에 EVM과 같은 실행머신이 없고(물론 eWasm이 대두되는 등의 이유도 있지만) 그런 머신을 사용하여 투표나 계산을 안해도 되니 그만큼 검증이 효율적이며 가스가 필요없게 된다. 뿐만아니라 일괄서명(aggregate signature)이라는 기법 덕분에, 모든 투표를 순서대로 긴시간동안 건건이 처리하지 않고, 심지어 오프체인상에서 충분히 모아질때, 즉 충분히 많은 검증자들이 지원하게될때(=스테이킹을 충분이 많이 하게될때), 체인에 전송 및 통합이 이뤄지고 이 과정을 보다 용이하게 만든다. 그덕에 비콘체인은 부하를 줄일수 있게 되고, 검증자들이 더 많이 참여하게 되며, 자연적으로 그만큼 탈중앙화되고 네트워크 보안도 올라가게 됩니다. 실제로 현재 이더리움 설계상에서는 벨리데이터 '참여'수가 최대 900정도에 불과하지만, 이더리움2.0설계에서는 그 '참여'수가 30만명도 커버가능하며, 시스템은 무려 최대 2^22(약 4백만)명까지 '지원'할수 있습니다. 이 2^22이라는 수치가 중요한 이유는 '시스템이 지원가능한 벨리데이터 수'가 클수록 '스테이킹할때 최소 이더수량'이 작아지기 때문이다. 가령 현재 이더 총 발행량이 2^27(약 1억 3천개, 실제론 1억 좀 넘음)이라하면 이더체인이 견딜수 있는 최대 오버헤드(초당 메시지)를 감안할때(이더측에서는 5천~6천정도 견딜수있을것으로 보고있음), 벨리데이터가 최대 2^22인데, '총 발행량/최대 벨리데이터'를 계산하면 2^5 즉 32ETH가 나오고 이게 바로 현재 계획상의 이더리움2.0에서 스테이킹할때 최소 이더수량이 나온다. 기사를 보며 생각한 두번째는, 이더리움 합의방식의 전환과 기관 진입입니다. 기사내용에서 부테린 군이 언급한 '기관 진입'이 '이더리움을 사용'할 기관 또는 프로젝트 추진 주체로 저 역시 해석했지만, 동시에 떠올린게 '이더를 매수'할 기관 또는 프로젝트 추진 주체였다. 제가 아는 소식통에 따르면 기관들이 이더매수에 다소 관망한다고 들었다. 왜 그런고 하니, 이더리움 행보가 투자하기에 애매하답니다. 확장성 해소도 문제지만, PoW에서 이더리움2.0에서의 PoW/PoS -> Full PoS까지 가는 여정이 너무 리스크가 크다는 것이다. 보통 여윳돈으로 코인에 투자하는 상대적으로 리버럴한 개인투자자들과는 달리, 우리가 생각하는 이상으로 보수 투자자들인 기관들은 '이더가 이더인건 알겠지만, 여튼 적극적일수는 없다'라는 것이다.
  - 항상은 아니지만, 유의미한 혁신은 변방에서 오기도 한다. 라이트 형제가 '사람을 날게하는 기이한 기구'라는 당시 획기적인 아이디어를 실행에 옮겼지만, 향후 수백명을 태울 보잉기나 레이더에 안 잡히는 스텔스를 생각하진 않았을겁니다. 마찬가지로, 부테린 등 이더리움 설립자들도 '월드컴퓨터'라는 현재로서는 원대한 컨셉을 잡긴했지만 어떻게 성공하거나 변질될지 모른다. 다만, 비행기가 다양한 기업들의 진입과 수많은 수요 덕분에 하나의 거대한 산업과 대중적 수용을 이룬것처럼, 이더리움도 체질개선 잘 하고 특이점만 넘으면 산업표준은 물론 인류사회의 한 페이지를 장식할수도 있다. 그런데 아직은 그 꿈의 궁전은 요원하고, 거길 가려고 해도 수많은 하드포크와 이더리움2.0이라는 큰 변곡점을 앞두고 있습니다.


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

[Ethereum] '제68차 이더리움 개발자 회의' 분석 및 개인 논평(8월 16일) v1.0

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

- 관련 링크 : https://github.com/ethereum/pm/issues/119



□ 로드맵(https://eips.ethereum.org/EIPS/eip-1679

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

□ 이스탄불HF 관련 EIP 관련

  ㅇ 이스탄불HF 허용(+잠정보류) EIP에 대한 클라이언트 업데이트
    - (Nethermind) 우리는 EIP-1344만 실행하였고, EIP-152, 1108, 2028, 1884, 2200은 아직 실행하지 않았습니다.
    - (Geth) EIP-1344, 1108, 2028, 1884를 실행하였고, EIP-152, 2200은 아직 실행하지 않았습니다.
      * 그 외 클라이언트는 불출석 등으로 언급이 되지 않았음

  ㅇ 잠정보류된 EIP에 대한 결정
    - EIP-2200과 EIP-1884은 이견없는 합의가 이루어졌다고 판단되므로 이스탄불HF에 허용될 예정이다.

□ 적합성 테스트

  ㅇ 테스트를 위한 공간, Gitter channel과 ReTestEth
    - HF에 포함될 EIP는 테스트가 반드시 행해져야하며, 그 테스트는 EIP제안자나 담당자가 수행하여야 한다. 다만, 제안자나 담당자가 의욕이 넘쳐도 어떤 테스트가 필요하는지 어떻게 그 테스트를 할수 있는지 모를때가 있는데, 이럴경우에는 다른 개발자들이 그 테스트를 용이하게 할 방법을 제시할수 있다. 이를 위해서 Gitter channel이나 ReTestEth와 같은 것을 통해 테스트를 하면 여러 클라이언트를 통해 테스트를 할수 있을것이다.

□ 테스트넷 업그레이트 및 이스탄불HF 후속 단계

  ㅇ 9월 4일(수) 테스트넷HF의 블록넘버 
    - 이제 막 이스탄불HF에 포함될 EIP를 정했고 Parity측이 회의에 참석하지 않은 관계로 우리는 테스트넷HF 블록넘버를 정할수 없으며, 그 블록넘버는 다음 개발자 회의에(또는 Gitter를 통해) 결정될것이다.
    - 이에 모든 클라이언트들은 다음 개발자 회의가 열리는 8월 23일(금)까지 이스탄불HF에 포함될 모든 EIP를 실행할수 있도록 준비하기를 바란다.

  ㅇ 이스탄불HF를 두번에 걸쳐 실시
    - 우리는 EIP-1057(또는 ProgPoW)와 같이 이스탄불HF에 포함시키고 싶지만 아직 준비가 되지 않은 EIP가 있기때문에 이스탄불HF를 부득이하게 두번에 걸쳐 실시할 예정이다.

□ HF를 모아서 할것인가 여러개로 나눠서 할것인가

  ㅇ 모아서 HF하기
    - HF가 준비된 EIP를 풀에 대기시켜 여러 EIP를 한번에 구현함으로써 예상가능한 시간간격대로 계획을 수립할수 있으며 HF와 관련된 사안들을 더욱 컨트롤할수 있는 여지가 있다. 다만 HF 검토 기한에 쫓겨 EIP담당자들이 다소 서두를수 있다.

  ㅇ 나눠서 HF하기
    - 충분히 준비가 되었을때 EIP를 제안하고 개별HF를 추진할수 있다. 다만, 수많은 개별HF를 추진해야하므로 그 과정에서 혼선이 발생할수 있다.

  ㅇ 근본적인 문제 
    - 모아서 또는 나눠서 HF를 하는것도 중요하지만, 더 중요한 문제는 EIP가 HF로 구현될때까지 많은 검토가 이루어지지 않는다는 점이다. 실제로 아무도 EIP를 모니터링하지 않으며 마지막 점검시 아무도 주의를 기울이지 않는다는 것이다. 따라서 클라이언트들은 초반부터 제안된EIP를 받아들이되 회의에 참석하여 그 EIP진행여부를 따져봐야한다.
    - 또다른 걱정거리는 누군가 EIP를 제안하고 그것에 대해 구축, 실행, 실행하기도 전에 클라이언트들로 하여금 그게 좋은건지 나쁜건지 파악해달라는 듯 하는 태도다.
    - EIP 프로세스의 문제점은 전체적인 프로세스를 추적할수 없다는 점이며, 그것을 타개하기 위하여 EIP진행상황을 시각적으로 표현하여 많은 당사자가 언제 EIP를 살펴봐야하는지 알수있게 하는 것이다. 클라이언트 관점에서 진행상황을 모니터링하기 위해서는 대시보드를 활용하는 것도 좋다.
    - 방금 논의된 것들은 모두 합리적으로 보이며, 어떻게 해야하는지 당장 결정할 필요는 없지만 더 논의하기로 한다.

□ HF 이름 짓기

  ㅇ 이스탄불HF 이후의 HF
    - HF 이름을 지어내는것은 지난 4월부터 시작된 오래된 토론 안건으로, 이스탄불HF가 두 차례에 걸쳐 실시되어 다시 논의하게 되었다. 2번째 이스탄불HF는 이스탄불HF 2 외에 다른 이름으로 불리는게 어떤가.
    - 이스탄불HF이후의 HF는 데브콘이 열린 도시의 이름을 따서 명명하기로 한다(가령 이스탄불HF 2는 데브콘0이 개최된 베를린HF로 하는식)


  ※ 이스탄불HF 결정 사안

    < 확정 EIPs > 2019년 10월 이스탄불HF에 반영 
     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사용을 불허함.

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


□ 개인 논평

  ㅇ 이더리움 발행률과 수익률
    - 지난 67차 이더리움 개발자 회의의 개인 논평에서 필자는 이더리움2.0에 대하여 설명하였다. 만약 당신이 이더 투자자라면 이더리움2.0에서 가장 관심있는 사안은 아마도 PoW에서 PoS로의 합의프로토콜 전환일것이고, 그중에서도 자금 예치 및 유효성 검증, 즉 스테이킹에 대한 관심이 클 것이다.
    - 그런데 이 스테이킹과 연관된 요인이 있으니 바로 '발행률'이다. 한 자산의 공급을 조절하면 (수요 등 다른 요인은 동일하다는 전제하에) 그에 따른 가치가 변한다는 것은 다 알것이다. 다만 네트워크에서는 그런 공급과 가치에 따라 네트워크 보안과 유동성에도 매우 큰 관련이 있다는 점도 반드시 알아야 한다.
    - 이러한 이더의 통화정책을 좀 더 알아보기위하여 이더의 발행 추이를 사진을 통해 알아보겠다.
< 이더 발행률(주황색)과 발행량(파랑색)의 추이(https://medium.com/ethhub) >

    - 이더는 난이도 폭탄, 주요HF, 이더리움2.0의 2단계(샤드체인도입) 등 굵직굵직한 이벤트마다 급격한 발행률 변동을 보이고 있다. 그런 발행률 추세는 점점 더 발행이 줄어드는 추세를 보이고 있으며, 그럴때마다 총 발행량은 원만한 곡선을 보이고 있다. 여기서 이더리움 네트워크의 가장 이상적인 모습은, 보다 낮은 발행률을 보이면서도 네트워크 보안성을 높은 상태일것이다. 그런데 발행률이 낮으려면 그만큼 유효성 검증자가 적어야하는데, 네트워크 보안성이 높아지려면 유효성 검증자가 많아야한다.

< 이더리움2.0에서의 이더발행과 스테이킹이율(https://docs.ethhub.io) >

    - 바로 위의 사진에서 보면, 유효성 검증에 활용되는, 즉 스테이킹된 이더가 적을수록 발행률은 작지만 소수의 고래들이 네트워크를 컨트롤할 확률이 높아지기에 보안리스크는 크다고 볼 수 있다.
    - 물론 이 모든 분석이 다음과 같은 변수들은 고려하지 않은 것이다. 첫째 변수는 '이더의 가격'이다. 아시다시피 암호화폐의 가격 변동성은 매우 큰 편으로 가격에 따른 스테이킹비율에도 적지 않은 영향이 있을수 있다. 둘째 변수는 '이더리움2.0의 구조적 요인'이다. 현재까지 밝혀진바로는, 이더리움2.0의 0단계(2020년 초)에서 2단계(2021년)까지는 체인안팎, 즉 기존PoW체인과 비콘체인 간 이더의 전송이 불가하다. 다시 말해, 2020년 초에 비콘체인이 도입되어 유효성 검증이 개시될때, 당신이 새로운 버전의 이더로 마이그레이션 후 스테이킹 할 경우 그 스테이킹한 이더는 2021년 샤드간 전송이 가능할때까지 거래소로 옮길수도 현금화 시킬수 없다(현재까지 알려진 바로는 다른 검증자에게 팔수 있단다). 셋째 변수는 '투자자 심리'다. 앞서 말한 첫째, 둘째 변수보다 더욱 근본적인 변수로, 이더 투자자가 이더를 갖고있을것인가에 대한 사안이다. 즉, 이더의 투자성이 크다고 하면 홀딩은 물론 스테이킹까지 할것이며 투자성이 적다고 하면 이더 발행률과 수익률과는 무관한 현금화, 타 코인 투자 등을 선택할것이다.
    - 뭐 복잡하게 얘기했지만, 간단하다. 주시하고 공부하고 투자하라. 그것을 위하여 간단명료한 힌트를 드리자면, 10월에 있을 Devcon5이스탄불HF, 2020년 초에 있을 이더리움2.0 0단계또다른 HF가 우리를 기다리고 있다. 혹시 아나, 비트코인 다음으로 이더리움이 BAKKT에 연내 상장될지(이 글이 성지가 되길).
    - 하지만 이런 큰 이벤트들이 이더의 떡상을 부른다는 것은 희망사항일뿐, 그때마다 엄청난 리스크가 동반된다는 사실도 명심하길 바란다. 그럼에도, 우리의 인생이 '매순간의 결정이라는 블록''그 결정에 따른 책임이라는 체인'으로 구성되어있다고 한다면, 당신만의 그 '블록체인'이 꼭 성공하는 프로젝트가 되길 바라면서 이번 논평을 마치겠다.


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


<Reference>
 1) https://medium.com/ethhub/the-basics-of-ethereum-2-0-economics-3bd2ffc7fd0e
 2) https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-economics

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

Raven Devs Meeting(16 Aug 2019) // 8월 16일 레이븐 개발자 회의 분석 및 논평


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

□ Analysis of the meeting by subject

  ㅇ ASIC mining machine launch and how to beat ASIC mining
    - ASIC mining machine has been released and is already being sold through some sites. The machines on sale are as follows.

    - When changing Raven algorithm, devs discussed time frame from one week to eight weeks. And when deciding to change the algorithm, it will be mandatory change rather than community voting.
    - Tron Black(Tron) said the ASIC miners on sale are only 30% more efficient than GPUs, although they are cheap, and do not make a big difference (in terms of hash power and centralization) and therefore do not have a big threat. However, he said that the machines need a response. He also said he has an idea that will make GPU miners happy, and that a detailed change will be unveiled on Monday.
    - The existence of ASIC mining is against Raven's philosophy as stated in its White Paper, so devs will try to resist ASIC mining.
    - Tron said the proposed change would be small, and the so-called x16r2 would retain 16 sub-algorithms but could change rotation. However, he said that it would resist the current ASICs but not new ASICs. And this economics of the race is in our favor because of the cost of making ASICs that will be obsolete. The biggest risk is when mining hash power of less than 50 percent did not participate in the upgrade. For this reason, he said, we should make sure that almost everyone participates in the change.
    - Other devs expected to upgrade legit mining pools such as supernova, minermore, ravenminer, nanopool and beepool, and said it was very important for exchanges to join the upgrade.
    - Monero's introduction of CNv4, an ASIC resistance algorithm, is another option, but devs are now looking for lighter changes, Tron said. The reason is that CNv4 is CPU-friendly and its CPU mining will on the rise because botnets (which means malicious software that is planted to use the computer without the knowledge of the computer's owner) could be a problem.
    - When asked by a dev what to do to prevent ASIC, Tron said that we need to resist ASICs (with a small change) as we promised and schedule them so that we do not conflict with the introduction of restricted asset functions. He also said that if ASICs become more dominant, devs will focus more on the timing of the change and in that case, we should ensure that exchanges upgrade as well.
    - A dev said another Raven(Raven Classic) coin could come out if a hard fork activate. Another dev said that there is someone who owns a mining farm of 1GH at 800W. Changing the algorithm will reveal whether this is ASICs or GPUs.


□ Personal Comment

  ㅇ ASIC issues again
    - There was a heated discussion of ASIC resistance during dev meeting on July 19. Then, four weeks later, we have seen another devs' discussions on ASIC resistance again because of the ASIC miners sold to the public.
    - I will explain once again now that some people still don't know the importance and reason for ASIC resistance (this cannot be stressed enough). ASIC mining is an unacceptable issue for the Raven project, and it has already promised ASIC resistance through its white paper. If ASIC mining is left unattended, a small number of ASIC miners will monopolize the hash power and control the economy and the operation rights, which could result in catastrophic damage to network maintenance and security. In other words, the decentralization of authority would be collapsed.
    - The advent of ASIC miners means that the prelude to undermining the value of decoupling centrality that we must uphold has been raised. Some may question whether ASICs can be prevented in advance. It is theoretically yes, but it is practically impossible. It's like having a new disease or virus come out and then getting rid of it or a vaccine to weaken it.
    - Therefore, devs are forced to quickly change its algorithms before new ASICs are mass-produced whenever ASICs appear. In addition, the change must be made by miners and exchanges on time to maintain network security and manage liquidity. If Raven, which follows the existing chain, uses the same name as Raven Classic and engages with some exchanges, things get complicated.
    - The problem isn't over here. Raven devs are currently testing major features such as restricted assets and dividends to be on the mainnet, and it is also very important to activate them quickly. Thus, as Tron said, algorithm changes and activations of key functions should not conflict with each other or one should not be ignored because of the other.

  ㅇ We don't have the royal road but our own answer.
    - As mentioned repeatedly, if ASIC resistance is a matter of 'survival' for Raven, the development is a matter of 'well-being'. The Raven devs and community may have to play a seesaw game of 'survival' and 'well-being' in the long-term.
    - There are not one or two projects that have already been slashed by ASICs, and Ethereum and Monero are also struggling to resist ASICs.
    - The community's role in this game, which may be tough, is very important. As anyone knows, Raven is a special project. I won't explain why and what it is special here because it's already known in other writings, but it would be a very sad if this great project collapsed in the adversity of ASICs. Therefore, we need to concern and support it.
    - I dare say it, considering that most of you are Raven investors. We are probably the ones who discovered the value of Raven too early and then put our money into it. That's why some now in the red and may be emotionally watching Raven's price. However, based on the rational judgment of the time when you decided to invest, I hope you understand Raven's ASIC resistance and development as much as you invested. In the process, I hope devs will be guided so that they don't get lost by supporting what we think is right and criticizing what we think wrong.
    - In the end, when Raven's potential becomes a reality, I really hope that you get good return than you have invested in it.

(한국어) 

□ 소재별 회의 내용

  ㅇ ASIC 채굴기 출시와 그에 대한 대응책 모색
    - ASIC 채굴기가 이미 출시되었고 사이트를 통해 이미 판매되고 있다. 그 판매중인 채굴기들은 다음과 같다.
    - 레이븐 알고리듬 변경시, 변경주기를 어떻게 설정해야하는지에 대한 논의가 있었고, 짧게는 1주일부터 길게는 8주까지 다양했다. 그리고 알고리듬 변경을 위한 결정을 할때, 커뮤니티에 의한 투표나 의견수렴보다는 강제적인 시행이 옳다는 의견이 더 많았다.
    - 트론블랙(이하 '트론')은 현재 판매중인 ASIC 채굴기는 저렴하기는 하지만, GPU보다 30%정도 더 효율적이라고 말하면서, (해시파워, 중앙화 측면에서) 큰 차이를 일으키지 않으며 따라서 큰 위협은 아니라고 말했다. 다만, 그에 대한 대응은 필요하다고 했다. 아울러 그는 GPU채굴자들을 행복하게 할 아이디어가 있다면서, 월요일에 세부적인 알고리듬 변경안이 공개될거라고 말했다.
    - ASIC채굴이 존재한다는 것은, 레이븐 백서에 명시된 레이븐의 철학에 위배되는 것이며, 따라서 개발자들은 ASIC채굴을 저항하는데 노력할것이라고 말했다.
    - 트론은 제안된 알고리듬 변경은 작을것이며, 이른바 x16r2라고 불리는 이 알고리듬은 서브알고리듬을 16개로 유지하되 로테이션을 바꿀수도 있다고 말했다. 다만, 그것은 현재의 ASIC채굴기를 저항시킬뿐, 향후 새로운 ASIC채굴기를 막진 않을거라고 했다. 그리고 (변경된 알고리듬에 의해) 쓸모없어질 ASIC 채굴기의 제작 비용때문에 이 경제싸움은 우리가 유리하다고 말했다. 가장 큰 리스크는 50%이하의 채굴 해시파워가 알고리듬 변경 업그레이드에 동참하지 않았을 때다. 이런 이유로, 그는 우리는 거의 모든이들이 알고리듬 변경에 참여하는 것을 확실하게 해야한다고 말했다.
    - 이에 다른 개발자들은 supernova, minermore, ravenminer, nanopool, beepool 등과 같은 합법적인 채굴풀들은 업그레이드 할것이라고 예상하였고, 거래소들이 업그레이드에 동참하는게 매우 중요하다고 말했다.
    - 일전에 모네로의 ASIC 저항 알고리듬인 CNv4 도입 역시 하나의 선택지지만 현재로서는 좀더 가벼운 변경안을 모색중이라고 트론은 말했다. 그 이유는 CNv4는 CPU친화적이라 CPU채굴이 늘어날텐데 그 경우 봇넷(필자주 : 컴퓨터 주인 몰래 그 컴퓨터를 사용하기 위해 심는 악성 소프트웨어를 의미)이 문제가 될수 있기 때문이라고 말했다.
    - ASIC을 막기위해 무엇을 해야하는지 묻는 한 개발자의 질문에, 트론은 작은 알고리듬 변경을 통해 우리가 약속한대로 ASIC을 무기력하게 만들어야하고 제한자산 기능 도입과 충돌하지 않도록 일정을 짜야한다고 말했다. 또한, 만약 ASIC이 더욱 지배력이 높아지면, (알고리듬 변경) 시점에 대해 더욱 집중할것이며, 그 경우 거래소들 역시 업그레이드 하도록 확실히 해둬야 한다고 말했다.
    - 한 개발자는 알고리듬 변경을 위한 하드포크를 할경우, 또 다른 레이븐(레이븐 클래식) 코인이 나올수 있다고 말했다. 또다른 개발자는 현재 800W에 1GH를 뽐내는 채굴농장의 소유자가 있다면서, 알고리듬 변경시 이것이 ASIC채굴인지 GPU채굴인지 드러날것이라고 말했다.

□ 개인 논평

  ㅇ 또다시 불거진 ASIC 이슈
    - 지난 7월 19일 개발자 회의때 ASIC저항에 대한 열띤 논의가 있었다. 그러부터 4주가 지난 현재, 우리는 대중에게 판매되는 ASIC채굴기때문에 또한번 ASIC저항에 대한 개발자들의 논의를 목격하였다.
    - 여전히 ASIC저항의 중요성과 당위성에 대하여 잘 모르는 분들이 있을까봐 다시한번 설명해드리겠다(이는 아무리 강조해도 부족하지 않다). 레이븐 프로젝트에 있어 ASIC채굴은 허용될수 없는 사안으로, 이미 백서를 통해 ASIC저항을 약속했다. 만약 ASIC채굴을 방치한다면, 소수의 ASIC채굴자들이 해시파워를 독식하면서 그들에 의해 경제권과 운영권이 좌우될것이고, 이는 네트워크 유지 및 보안에 치명적인 손상이 가해질수 있다. 즉, '권한의 분산'이라는 탈중앙성의 가치가 무너지는 것이다.
    - 본문에서 언급한 채굴기의 등장은 우리가 반드시 지켜야할 탈중앙성의 가치를 훼손할 서막이 올라갔다는 의미다. 혹자는 ASIC을 미리 막을수 없냐고 의문을 가질수 있다. 이론상 가능하지만, 실제로는 거의 불가능하다. 이는 마치 새로운 질병이나 바이러스가 나타난 뒤에 비로소 그것을 없애거나 약화시키는 의술이나 백신이 나오는 것과 같다.
    - 따라서 개발자들은 ASIC이 나타날때마다 새로운 ASIC채굴기가 양산되기 전에 그때그때 재빠르게 알고리듬을 변경할수밖에 없다. 또한, 그 변경을 채굴자들과 거래소들이 제때 업그레이드를 하여 네트워크 보안 유지 및 유동성 관리를 해야한다는 점이다. 이때 기존 체인을 따르는 레이븐코인이 '레이븐 클래식'같은 이름을 달고 일부 거래소와 결탁을 한다면 일은 복잡해진다.
    - 문제는 여기서 끝이 아니다. 우리에겐 현재 제한자산, 배당 등과 같은 주요 기능들이 메인넷에 올려지도록 테스트중인데 이 기능을 빨리 활성화하는 것도 매우 중요하다. 따라서 트론이 말한것처럼, 알고리듬 변경과 주요 기능의 활성화가 상호 충돌하거나 어느 하나가 다른 하나때문에 묻혀지면 안된다.

  ㅇ 왕도는 없지만 그만의 정답은 있다
    - 누차 언급한대로, 레이븐에게 있어 ASIC저항이 '생존'의 문제라면 개발상황은 '웰빙'의 문제다. 레이븐 개발자와 커뮤니티는 앞으로 기나긴 '생존'과 '웰빙'의 시소게임을 해야할지도 모른다.
    - 이미 ASIC에 난도질 당한 프로젝트는 한두개가 아니며, 그 유명한 이더리움과 모네로 역시 ASIC저항 이슈는 합의가 잘 안되는 안건들 중 하나이다.
    - 험난할지도 모르는 이 게임에 있어 커뮤니티의 역할은 절대적이다. 아는 사람은 알겠지만 레이븐은 특별한 프로젝트다. 왜 그리고 무엇이 특별한지는 다른 글들을 통해 이미 알려져있으므로 여기서 굳이 언급하지 않겠지만, 이런 특별한 프로젝트가 ASIC이라는 역경에 무너진다면 매우 안타까운 사건이 될것이다. 따라서 우리 커뮤니티의 관심과 지지가 필요하다.
    - 필자의 글을 읽는 대부분이 레이븐 투자자임을 감안하여 감히 말씀드린다. 우리는 어쩌면 너무 일찍 레이븐의 가치를 발견하고, 거기에 본인 자산을 투입한 사람들일지도 모른다. 그 탓에 현재 손실권에 들어갔고 따라서 감정적으로 레이븐을 지켜볼지도 모른다. 하지만 현재의 부정적인 감정은 조금 내려놓고 투자하기로 결심했던 당시의 이성적 판단에 따라, 적어도 투자한 만큼 레이븐의 ASIC저항과 개발상황을 숙지하기를 바란다. 그런 과정에서, 옳다고 생각하는 것에는 지지를 옳지 않다고 생각하는 것에는 비판을 하여 개발자들이 길을 잃지 않도록 길잡이가 되어줬으면 좋겠다.
    - 마지막으로, 향후 레이븐의 잠재력이 현실화될때, 당신이 레이븐에 관심을 갖고 투자한 것 이상으로 수익을 내기를 진심으로 바라면서 이번 논평을 마치겠다.


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

[Poem] 오감불만족(五感不滿足) v1.0

< 오감불만족(五感不滿足) >

 - 코인논객시인 오공


< Agony(괴로움) by Marcus Ortega(https://fineartamerica.com) >

나는 눈이 있어 괴롭다
쉼없이 등락하는 차트의 물결속에서
투자한 코인이 하락하는걸 보니 괴롭다

나는 귀가 있어 괴롭다

지인으로부터 투자성이 좋다는 소문을 듣고선
덜컥 사놓고 존버한 코인이 폭망해서 괴롭다

나는 냄새를 잘 맡아 괴롭다

남을 못 믿겠어서 스스로 공부하다가
대작나무 타는 냄새가 나서 샀더니 물려서 괴롭다

나는 맛에 예민해 괴롭다

몇번 당해보니 메이저코인이 최고같아서
입맛에 따라 사놨더니 비트코인만 상승해 괴롭다

나는 섬세한 촉각때문에 괴롭다

내 처참한 포트폴리오를 쳐다볼때마다
누가 안 건드려도 꼬집힌듯 고통을 느껴지니 괴롭다

이쯤되면 오감을 소유한 그 자체가 불만인 나는

다름아닌 오감불만족의 소유자 같다
그런데 남들이 모르는 나만의 감각, 육감이 있다

육감은 외부자극에 지배당하는 오감과는 달리

스스로 통제하고 관리할수 있는 나의 소중한 감각이다
다만 안타깝게도 너무 변화무쌍하다는 문제가 있다

때로는 희망회로에 불타 탐욕의 모습이 되기도 하고

때로는 현자타임이 와서 겸손의 모습이 되기도 한다

우리는 오감불만족인가 아니면 육감마저 불만족인가

하지만 그에 대한 진지한 고민을 하기는 커녕
오늘도 우리는 보고 듣고 맡고 맛보고 뜯기며 괴로워한다

[Ethereum] '제67차 이더리움 개발자 회의' 분석 및 개인 논평(8월 2일) v1.0




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

- 관련 링크 : https://github.com/ethereum/pm/issues/116


□ 이스탄불HF 관련 이더리움개선제안(EIPs) 관련

  ㅇ 이스탄불HF 허용(+잠정보류) EIP에 대한 클라이언트 업데이트
    - 지난 회의를 통해 도래하는 HF는 올해 10월과 내년 초에 진행할수 있다는 가능성을 열었습니다. 또한, 이더리움 개발자들은 지난 회의를 통해 이스탄불HF에 허용 또는 잠정보류된 EIP에 대한 논의를 하였고, 그 EIP에 대한 각 클라이언트에 대한 업데이트를 하기로 하였다.
     - (Pantheon) 우리 Pantheon은 EIP-1057(ProgPoW 관련), EIP-1962(타원곡선 관련)을 구현하지 않았습니만, 우리의 개발 상황에서 허용 또는 잠정보류된 EIP 사양에 맞도록 구현하겠다.
     - (Nethermind) 우리는 EIP-1344(체인ID관련)와 EIP-2028(가스비 절감 관련)을 받아드렸고 EIP-1057(ProgPoW 관련)은 제외했으며, EIP-1962(타원곡선 관련)은 진행중에 있습니다. 나머지는 곧 시작하거나 중요하게 보고 있지 않습니다.
    - (Geth와 Parity) 이 두 클라이언트의 업데이트는 중요하므로, 다음 회의 전까지 실행하기를 바란다.

  ㅇ 이스탄불HF 잠정보류EIP 관련
    - 우리는 EIP-2045(EVM opcode상의 입자 가스비 관련)*가 잠정보류될만한 개선안이라고 보고 있다. 별도의 서브루틴을 도입하지 않아도 되고 점프작동방식을 변경하지 않아도 (확장성 해결을 위한) 속도향상을 기대할수 있다. EWASM팀의 관점으로 볼때도, EWASM의 잠재적 이점들 중 하나는 속도를 높이는 것이므로 입자 가스비 관련 EIP-2045는 EWASM에 있어서도 좋은 대안이 될것입니다. EVM과 클라이언트간 호환성을 최적하하면 EWASM을 활용하는 것보다 쉽고 빠를수도 있다.
      *EIP-2045(https://eips.ethereum.org/EIPS/eip-2045) : 이더리움 거래량, 즉 확장성은 '블록가스상한(가스제한)'에 따른 '가스비'에 의해 결정됨. 이 거래량을 높이기 위한 하나의 방법은 '가스제한'을 높이는 것'임. 단, 가스제한을 높이면 스테이트 증가율도 올라가며, 이는 가스비의 경제성 가정전환 문제나 컨트렉트 실행상 변수 문제 등의 부작용을 낳음. 거래량을 높이기 위한 또다른 방법은 '가스비를 줄이는 것'임. Computational opcode의 가스비를 줄이면, 가스제한을 높이고 storage opcode를 높이는 효과가 나면서도 부작용은 없음. 그런데 이 computational opcode의 가스비가 1에 가까우므로 가스비 측정치를 더 잘게 쪼개면서 EVM에서 실행하는 것을 시험해봤는데 그 결과가 괜찮았음. 이때 더 잘게 쪼개진 가스비 측정치를 '입자(Particles)'라고 함.
    - 이미 가스비와 관련된 EIP-1108, 1884, 2028이 확정 또는 잠정보류되었기 때문에 이것에 집중하는 것이 좋다고 생각한다.
     - 가스비 관련 EIP를 포함한 모든 잠정보류 EIP는 HF에 반영되기 위하여 많은 벤치마킹이 필하며, 담당자가 벤치마킹과 관련된 많은 작업을 해야한다. 또한 올해 10월 HF에 미반영되면 내년 4월이든 7월이든 차기 HF에 반영될수도 있다.
     - 앞으로 도래할 HF반영에 잠정보류된 개선안은 EIp-663, 1380, 1985, 2045, 2046이며 이들의 벤치마킹은 시급하다.
      1) EIP-663(https://eips.ethereum.org/EIPS/eip-663) : 현재 스택상 16의 깊이로 제한된 SWAP과 DUP명령어를, SWAPn과 DUPn으로 대응시키고 모든 깊이까지 접근을 허용함.
     2) EIP-1380(https://eips.ethereum.org/EIPS/eip-1380) : 자기호출에 대한 가스비 절감으로, 현재 로드된 컨트렌트의 새 인스턴스를 실행시 호출지시에 대한 가스비를 줄임.
     3) EIP-1985(https://eips.ethereum.org/EIPS/eip-1985) : 가스제한, 블록넘버 등 EVM 매개변수들에 대한 적정 한계범위를 적용. 명시적인 범위를 적용하면 호환가능한 클라이언트를 구현하는데 도움이 됨.
     4) EIP-2035(https://eips.ethereum.org/EIPS/eip-2035) : 블록검증을 위해 SLOAD와 SSTORE실행시 지불해야하는 가격 재책정방식으로, 컨트렉트 스토리지 크기에 따라 비용이 달라짐(가령, 컨트렉트가 작을수록 저렴해짐). 


□ 적합성 테스트

  ㅇ ReTestEth
    - HF에 반영되기 위해서는 참조구현(Reference implementation)이 충분하고 테스트가 동반되어야 합니다. 이를 위해 클라이언트가 사용되는 도구들 중 하나가 'ReTestEth'입니다. 따라서, 우리는 잠정보류된 모든 EIP의 테스트를 위하여 ReTestEth 사용에 동의합니다. 


□ 워킹 그룹 업데이트

  ㅇ 잠정보류 EIP에 대하여
    - ProgPoW로 유명한 EIP-1057의 경우, 감사가 완료되지 않았다. EIP-1962의 경우, 정확성을 검토중입니다. 이러한 잠정보류건이 어서 테스트넷HF와 이스탄불HF에 허용되는 것이 우리가 바라는 것이며, 그렇지 않으면 내년에 있을 HF에 반영될것입니다. 


□ 개인 논평

  ㅇ 이더리움2.0 맛보기
    - 이더리움 개발자 회의가 1주일 간격으로 진행되었고, 계속해서 이스탄불HF에 반영될 이더리움개선안(EIP)에 대한 논의가 지속되고 있기때문에 딱히 논평할 거리가 없다. 그 대신에 이더리움2.0에 대한 설명을 하고자 한다. 
    - 최근 비탈릭은 트위터를 통해 이더리움2.0에 대한 대부분의 연구가 완성되었고 스펙은 계속 업데이트 된다고 언급하였다. 이더리움2.0으로 통하는 '세레너티(Serenity)' 단계는 이더리움 마스터플랜의 최종 단계로, 가장 두드러진 특징으로는 PoW에서 PoS로의 합의프로토콜 전환, EVM에서 EWASM으로의 가상머신 전환, 샤딩 도입 등이 있다. 여기선, 이더리움2.0에서의 스펙이 아직 최종적으로 확정되지도 않았고, 현재까지 밝혀진 내용도 워낙 방대하고 난해하기 때문에 모든걸 다루지 않고 이더리움2.0에서의 각 단계별 내용에 대해 간단히 알아보겠다.
< 이더리움2.0의 여러 체인(https://www.mycryptopedia.com) >


  <0단계> 비콘체인(Beacon Chain) - 2020년 초
   - 비콘체인만 다뤄도 아주 긴 글이 되겠지만, 그 개념과 역할 위주로 정리해보겠다. 비콘체인은 비콘체인 자체체인과 모든 샤드체인에 대한 스테이킹 증명 프로토콜을 총괄하는 체인이다. 이 체인은 검증인(블록을 생성하고 제안하는 '제안자' + 그 제안을 검증하는 '증인')과 그들의 스테이킹 관리, 각 샤드에 제안자를 추천, 검증인을 임의선정한 증인위원회 구성, 합의규칙 적용, 검증인에 대한 보상과 페널티 적용, 샤드간 거래를 위한 스테이트 등록 등의 역할을 수행한다.
     - 특히, 다음단계인 1단계에서 등장할 '샤드체인'과 관련된 역할이 있다. 샤드체인이 배치되면, 각 샤드는 샤드에서 실행된 트랜잭션을 블록화하는 검증인을 임의선정하며, 그 검증인으로 하여금 역시 임의선정된 샤딩버전의 증인위원회에 의해 투표하게한다. 이때 투표가 잘 이행되면 크로스링트가 생성되는데, 이는 곧 비콘체인에 트랜잭션 업데이트를 할 준비가 되었다는 뜻이다.
     - 0단계에서 주목할만한 점은 기존 ETH를 다른 버전의 ETH로 전환해야한다는 점이다. 이는 비콘체인에 사용될 새로운 자산(ETH2)으로, 비콘체인에서 스테이킹을 하고 검증인 역할을 하거나 기존의 ETH(ETH1)을 구매하여 비콘체인으로 전송하여 얻을수 있다. (단, 전송한 ETH1은 샤드간 전송이 불가하며 2단계가 완료되어야 샤드간 전송이 가능하다).
      - 참고로 유효성 검증과 그에 따른 보상을 받기 위한 스테이킹은 최소 32이더가 필요하다. 

  <1단계> 샤드체인(Shard Chain) - 2020년 
    - 샤드체인은, 성능과 관리를 개선하기 위하여 데이터를 수많은 조각과 공간으로 나눠 보관하는 확장성 기술인 샤딩을 총괄하는 체인이다. 이 단계에서 이더리움 체인에서 발생하는 트랜잭션이 1,024개의 샤드로 분산되며, 이때 기존보다 동일한 시간에 훨씬 더 많은 트랜잭션을 처리할수 있다.
     - 샤드체인이 도입되어도 기존의 PoW체인은 계속 작동하므로, 보상이 PoW채굴자와 PoS검증인 모두에게 지급된다. 

  <2단계> 스테이트 실행(State execution) - 2021년 
   - 새로운 체인이 도입되는 0단계와 1단계와는 달리, 2단계는 질적으로 여러 기능이 통합되는 단계다. 샤드체인은 단순 데이터 보관창고에서 더욱 구조화된 체인으로 탈바꿈되며, 각 샤드는 EWASM을 기반으로 가상머신을 관리한다. 또한 비로소 샤드간 ETH가 전송이 가능해진다.
    - 그리고 EWASM 스토리지 비용인 스테이트 임대수수료(State rent)제도가 도입되어, 스마트 컨트렉 개발자와 사용자는 코드와 데이터를 저장하기 위한 수수료를 지불해야 합니다.
 
  <3단계> 라이트 클라이언트 스테이트 프로토콜(Lightc-client State Protocol) - 2022년
    - 사용자들은 스토리지 임대수수료를 직접 지불하거나 2차시장(필자주 : 회사 경영권이 주식이라는 형태로 증권시장에 상장되어 거래되듯이, 스토리지 사용권도 별도로 거래될수도 있다는 의미같음)을 통해 지불될 예정이다.
     - 기타 세부 계획은 알려지지 않음.

  <4단계> 샤드간 트랜잭션(Cross-shard transactions) - 미정
    - 내부적으로 샤드와 샤드와 관련된 기술이 내실화된다.
    - 기타 세부 계획은 알려지지 않음.

  < 5단계> 샤드와 메인체인간 긴밀한 보안 공조(Tight coupling with Main-chain Security) - 미정 
    - 포크가 필요없는 샤딩기술이 도입된다.
    - 기타 세부 계획은 알려지지 않음.

  < 6단계> 샤드의 샤드(Super-quadratic or exponential Sharding) - 미정
    - 샤드안에 샤드가 있고 또 그안에 샤드가 있는 '재귀적으로 존재하는 샤드'가 도입된다.
    - 기타 세부 계획은 알려지지 않음.

  < 이후 단계> 이더리움3.0 - 미정 
    - 진정한 Full PoS기반의 이더리움이 구현될 예정이다. 또한 현재 영지식증명기술인 zk-SNARKs보다 더 진보된 zk-STARKs가 도입 및 결합될 예정이다.
     - '이질적인 샤드(Heterogeneous shards)'라는 것이 도입되어, 다른 샤드에 영향을 끼치지 않으면서 더 높은 가스 트랜잭션을 허용할수 있다.
    - 기타 세부 계획은 알려지지 않음.

  ㅇ 이더리움2.0 단계를 알고보니,,,
     - 이더리움2.0을 넘어선 이더리움3.0까지 작성하고보니, 이글을 읽고있는 누군가에겐 장투를 위한 유용한 정보가 될수도 있고, 다른 누군가에겐 장투하기도 전에 질려버릴수도 있다. 다만, 필자는 투자자이면서 분석가이기에 스스로 이더리움의 로드맵을 정리할 겸 소개할 겸 해서 정리하고 공유해봤다. 앞으로도 이더리움 개발자 회의와 직결되는 논평을 작성하기 애매할 경우, 이더리움2.0과 같은 이더리움의 다른 측면도 소개할예정이므로 기대하길 바란다.  


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


<Reference>
 1) https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-phases/
 2) https://github.com/ethereum/wiki/wiki/Sharding-roadmap#phase-3-light-client-state-protocol
 3) https://www.mycryptopedia.com/ethereum-beacon-chain-explained/
 4) https://medium.com/ethhub/the-basics-of-ethereum-2-0-economics-3bd2ffc7fd0e
 5) https://notes.ethereum.org/s/rkhCgQteN#Why-32-ETH-validator-sizes

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


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

□ Analysis of the meeting by subject

  ㅇ Progress of development of Restricted assets
    - Restricted assets are on the test net. In addition, GUI for Restricted assets is now being developed. Tron Black('Tron') said that we have finished its surface testing and some fixes, and we hope more people will join us to help the tests.
    - Another dev said that QT/GUI* would be released on testnet more and that it has not yet been fully tested to put Restricted asset function on mainnet. And when the GUI is released that will help devs check the code, it will start Bugbounty**, he said.
     * QT/GUI: Cross-platform for GUI development in computer programming field, or an open source development tool that anyone can use for free.
     ** Bug Bounty: Event to provide rewards to hackers who hack into their services and products and discover vulnerabilities
    - Tron said that $ and # are unique symbols for Restricted assets and tags, from RPC calls (in coding execution statement scheme), that we need 'Escaping Rules' putting \in front of $ or #.
     *** Remote Procedure Call (RPC) : As derived from the name, 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.

  ㅇ Progress of development of Dividends
    - Some devs of Dividends said we are testing and hope that updates will be on the mainnet in October at the latest. See here(https://github.com/RavenProject/Ravencoin/pull/600) for related flag links.

  ㅇ Other updates
     - As for hiring C++ developers to join the Raven core dev team, which has been announced since early July, a dev said we are go over cv's.
    - Tron and other devs said that once the tag is complete, the tagging address will burn Raven.

□ Personal Comment

  ㅇ Analysis of Development and Market Trend
    - Unlike the previous meeting where there was a long and hot debate on ASIC resistance, this meeting had a short discussion on the development process. In fact, while other channels still continue to discuss ASIC resistance and changing algorithms (a matter of 'Survival'), development progress(a matter of 'Well-being') such as Restricted assets and Dividends is also important, so it seems that core devs focused on them for now.
    - As a crpyo analyst, I mainly write articles about development or big insight, but this time I would like to make investor point. Since its all-time high in late March, Raven price has unfortunately been testing its support lines to date. The growing coin market has made us analyse the market more difficult, especially as the bitcoin market has grown in touch with real economy, and the analysis of the Altcoin market, 30% range of the whole coin marketcap, is almost impossible. Raven, a promising project with great potential but still weak fundamentals, is no exception to the uncertainty. So what should we do as a Raven investor, let alone put aside other coins?
    - Based on Satoshi scale, relatively new projects such as Raven are more responsive to 1) Bitcoin's market value, and 2) we just wait for Raven to finally check its support line in the current makret where Bitcoin alone dominates, 3)In that sense, it is recommended that HODL be placed as plan B, but, if necessary, it is recommended to consider buying on scale at the main knee point.
    - The reason for this analysis is 1) Bitcoin has been trying to break out the down trends the overall coin market in recent months, 2) it is possible to predict 'trickle down effect' of Altcoin according to numerous precedents, 3) Raven's case, from a market point of view, creates investor sentiment that it will show bigger wave in the future, and 4) community's support and voting power are getting stronger. 5) In addition, from a development perspective, Raven has increasingly clearly identified itself as a unique platform for generating and trading a wider variety of tangible and intangible assets starting with securities(this is very important, as I personally believe the next coinboom will be different from 2017's coinboom that appealed with the potential of relying on
white papers).
    - However, such an investment analysis should have the precondition that the trickle down effect from Bitcoin to Altcoins is also valid for Raven and that the potential of cryptocurrency, including STO, is consistent with the firm legislation of the authorities and the timing of the regulation. Other prerequisites and numerous variables will cover our front, and it seems that the next coinboom would be a gift without a promise.
    - Nevertheless, we are in a wriggling crypto market that could explode at any time. What we expect from this market is that it will receive capital commensurate with the 4th industrial revolution and take profits from the items we invested in. I wound not say in my personal comments that Raven just looks good and good things will happen in the den. Instead, I would say that it has a good investment potential for some reasons mentioned above. Now that the support line of Raven price is being 'tested' and also various asset-generating functions are being 'tested' on testnet, I'd like to know exactly what your opinion is.




(한국어) 

□ 소재별 회의 내용

  ㅇ 제한자산(Restricted asstes)의 개발 진행 상황
    - 제한자산은 테스트넷에 테스트중이다. 또한 제한자산을 위한 GUI(그래픽 유저 인터페이스)가 현재 개발중이다. (지난 한달동안 테스트넷에서의 제한 자산 개발 상황에 대한 질문에 대하여) 트론 블랙(이하 '트론')은 우리는 표면적인 테스트를 마쳤고 몇몇 오류를 잡아냈다고 말했고, 다른 개발자도 더 많은 사람들이 합류하여 테스트를 도와주기를 바란다고 말했다.
    - 또다른 개발자는, QT/GUI*가 구축되어 테스트넷에서 출시되면 더 쉽게 테스트를 진행할수 있을것이며, 아직까지 (제한자산 기능을) 메인넷에 올리기까지는 충분한 테스트를 하지 못했다고 말했다. 그리고 개발자들이 코드를 점검하는 것을 도울 GUI가 출시되면 버그바운티**를 시작할것이라고 그는 말했다.
     * QT/GUI : 컴퓨터 프로그래밍 분야에서 GUI(그래픽 유저 인터페이스)개발에 활용되는 상호호환 소프트웨어 개발도구(Cross-platfrom softward developmen)로 누구나 무료로 사용할수 있는 오픈소스 개발도구이기도 함.
     ** 버그바운티(Bug Bounty) : 자사 서비스와 제품을 해킹해 취약점을 발견한 해커에게 포상금을 지급하는 제도
    - 트론은 코딩실행문구에서 $와 #가 각각 제한자산과 태그를 위한 특별한 기호라는 점을 들면서, (코딩실행문구상) 이 기호들을 RPC 호출에서 제외할수 있도록 조치했다고 말했다. 그 조치는 제외규칙(Escaping Rules)을 두어 $ 또는 # 를 쓸때 그 앞에 \를 작성하도록 하는 것이다.
     *** RPC(Remote Procedure Call, 원격 프로시저 호출) : 이름에서 유추되듯이, 서로 떨어져있는 공간에서 동일한 코드를 활용하여 다양한 함수(절차) 등을 실행하게 해주는 통신기술로서, Remote Invocation(원격호출) 이라고도 함.

  ㅇ 배당(Dividends)의 개발 진행 상황
    - 배당기능의 관련 개발자는 현재 추가 테스트를 진행중이며, 늦어도 10월정도에 메인넷에서의 업데이트가 이뤄지기를 바란다고 말했다. 관련 깃헙 링크는 여기(https://github.com/RavenProject/Ravencoin/pull/600)를 참조 바란다.

  ㅇ 기타 사항
    - 7월초부터 공고한 레이븐 핵심 개발팀에 합류할 C++개발자 채용에 대해서는, 현재 이력서를 검토중이라고 한 개발자는 밝혔다.
    - 트론과 개발자들은 태그가 완성되고 자산이 생성되면, 태깅주소가 레이븐을 소각할것이라고 말했다.


□ 개인 논평

  ㅇ 개발과 시세 동향 분석
    - ASIC저항에 대한 길고 열띤 논의가 있었던 지난 회의와는 다르게, 이번회의는 개발 진행에 대한 짧은 논의가 있었다. 사실 다른 채널에서는 아직도 ASIC저항과 알고리듬 변경(생존의 문제)에 대한 논의가 계속 이어지고 있지만, 제한자산, 배당 등 개발진행(웰빙의 문제)도 중요하기 떄문에, 이번 회의때는 핵심 개발자들이 이 부분에 집중했던 것 같다.
    - 필자는 분석가로서 주로 코인 프로젝트의 개발상황이나 거대담론을 다루는 기고를 주로 하고 있지만, 투자자이기도 하기에 이례적으로 투자자관점으로 언급해보겠다. 레이븐 시세(사토시기준)는 3월말 전고점을 찍은뒤 안타깝게도 현재까지 지지선을 테스트중이다. 코인 시장이 점점 커짐에 따라 과거와는 다르게 특히 비트코인 시세가 실물 경제와 접점을 키우며 시세 분석이 더욱 까다로워지게 되었고, 코인 시총 중 30%대에 불구한 알트코인 시세의 분석은 거의 불가능할정도로 불확실성이 높다. 잠재력이 크지만 아직은 펀더멘털이 약한 유망주 '레이븐'도 그 불확실성에 예외는 아니다. 그러면 다른 코인은 제쳐두고라도 레이븐 투자자로서 어떻게 해야할까.
    - 사토시 기준으로 볼때, 레이븐과 같은 비교적 신생 프로젝트는 1)비트코인의 시세에 더더욱 예민하게 반응하고, 2)비트코인이 시장을 지배하는 현재로서는 진반등을 위한 지지선을 빠른 시일내에 확인(펀더멘털 키우기)하기를 바랄수밖에 없다. 그런의미에서 3)존버를 차선책으로 두되, 필요에 따라 주요 변곡점에서 분할매수를 최우선적으로 고려하는 것을 감히 권고한다.
    - 이렇게 판단하는 이유는, 1) 비트코인이 전체 코인 시장의 하락장을 벗어나려는 모습을 최근 몇달간 보여주고 있고, 2) 수많은 전례에 따라 언젠가는 알트코인으로의 낙수효과를 예상할수 있으며, 3) 레이븐의 경우, 시세 관점에서는, 점점 더 큰 파동을 그리며 향후 더 큰 시세상승을 보여줄거라는 투자심리를 심어주고 있고, 4) 커뮤니티 관점에서는, 각종 투표, 설문조사 등을 통해 상대적으로 막강한 결집력과 지원력 보여주고 있다. 5) 또한, 개발 관점에서도, 증권을 시작으로 더 다양한 유무형 자산을 생성하고 거래하는 고유의 플랫폼으로서의 면모를 점점 명확히 갖추고 있고 있기 때문이다(이 것은 매우 중요한데, 개인적으로 다음 코인붐은 백서에 의존한 잠재력으로 어필한 2017년 코인붐과는 다를것이라고 보기 때문이다).
    - 다만, 이런 투자 분석에는 비트코인의 알트코인으로의 낙수효과가 레이븐에게도 유효하다는 전제조건과 STO를 비롯한 암호화폐의 행보가 당국의 확고한 법제화와 규정마련과 타이밍이 맞고 잡음이 없다는 전제조건이 있어야 한다. 기타 다른 전제조건들과 수많은 변수들이 우리 앞을 가릴것이고, 그만큼 코인붐이 오는것은 기약없는 선물이라고 볼수 있다.
    - 그럼에도 불구하고, 우리는 여건만 된다면 언제라도 폭발할듯 꿈틀대는 암호화폐 시장에 들어와있다. 이 시장에서 기대하는 것은 4차 산업혁명에 걸맞는 자본금이 들어와 본인이 투자한 종목에서 수익을 얻는 것이다. 레이븐은 좋아보이니 존버하면 좋은일이 생길거라는 치기어린 조언은 필자의 논평에 쓰고 싶지 않다. 대신에 상기 언급한 요인들에 비추어볼때 개인적으로는 투자잠재성이 좋다고 말할수 있을뿐이다. 레이븐 시세가 지지선을 '테스트'하고 있고 다양한 자산생성 관련 기능들이 테스트넷에서 '테스트'되고 있는 현재, 여러분의 의견은 어떤지 그것이 알고 싶다. 


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

[Ethereum] '제66차 이더리움 개발자 회의' 분석 및 개인 논평(7월 26일) v1.0

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

- 관련 링크 : https://github.com/ethereum/pm/issues/113



□ 이스탄불HF에 포함/미포함

  ㅇ EIP-1344 : 포함
   < 부연 설명 >
    - EIP-1344(https://eips.ethereum.org/EIPS/eip-1344)은 컴파일링시 체인ID(서로 다른 체인간 트랜잭션 재생을 방지하는 수단)를 지정하고 opcode를 추가하면 그 체인ID에 접근하여 서명의 유효성을 검사하며, 따라서 다른 체인간 리플레이 어택 등을 방지할수 있다.
   < 회의 내용 >
    - 서명의 유효성을 검사하기 위해 체인ID를 체인상에 포함시킬지 아니면 트랜잭션상에 포함시킬지에 대한 논의가 있었고, 스마트컨트렉트 사용시 같은 체인으로부터 다른 체인ID를 받는 가능성이 있을수 있기때문에 체인상에 포함하는게 더 안전할거라는 의견이 있었다. 이때, opcode를 추가하여 opcode를 호출하면 공개되지 않는 넘버가 나오고 그 넘버를 갖고있을때만 체인ID에 접근하여 서명의 유효성을 검사할 수 있다. 이 개선안은 합리적이라는데 대부분 공감하므로 이스탄불HF에 포함된다.

  ㅇ EIP-1283EIP-1706, 그리고 EIP-2200 : 포함
   < 부연 설명 >
    - EIP-1283(https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1283.md)은 지난 콘스탄티노플HF에 적용될뻔한 EIP로, 총 가스 계량기(Net gas metering)를 변경하여 스마트컨트렉트 저장소를 위한 새로운 활용가능성과 대부분의 작동방식이 맞지 않을때 발생하는 과도한 가스비의 감소를 목표로 한다. 즉, 불필요한 가스비를 줄이는 코딩을 돕는다.
    - EIP-1706은 이스탄불HF를 위한 EIP-1283수정본으로, 가스비가 집행비(Call stipend)보다 낮은경우 SSTORE사용을 불가능하게 하자는 제안이다.
    - EIP-2200은 EIP-1283과 EIP-1706의 통합본으로 이스탄불HF에 적용시 이 두 EIP(1706, 1283)가 결합된다.
   < 회의 내용 >
    - EIP-1283은 상대적으로 간단한 개선안이며, EIP-1706를 보더라도 많은 변화가 있지는 않다. 지난 콘스탄티노플HF때도 도입될뻔한 개선안이므로 딱히 결함이 없다면 이스탄불HF에 포함시키지 않을 이유가 없다. 다만, 1283개선안을 선택할지 아니면 1706개선안을 선택할지에 대한 것은 논의가 필요하다. 어떤 버전의 EVM과도 호환가능한 개선안이 좋을것같고, 그런의미에서 2200개선안이 제일 나아보인다. 결론적으로 기술적으로 구현할 시간이 충분한지 살펴보고, 실행해보면서 유의미한 효과가 있는지 보기로 하고 이스탄불HF에는 포함시키기로 한다.

  ㅇ "ProgPoW" EIP-1057 : 보류
    - ProgPoW(https://eips.ethereum.org/EIPS/eip-1057)는 특정ASIC이 채굴할수 있는 작업유효간격을 좁히기 위해 고안된 PoW알고리듬으로, ASIC의 향상된 효율성을 반감시키위하여, 상용GPU자원을 최대한 활용되도록 수정하는 것이 ProgPow의 디자인이다.
   < 부연 설명 >
    - 우선 ProgPow는 ASIC채굴의 상대적 높은 효율성을 반감시키는 PoW변형알고리듬으로, AMD, NVIDIA 등이 제조하는 그래픽 카드에서 테스트되고 적용되며, 따라서 카드제조업체 및 산업에 적지않은 영향을 줄수 있고, 동시에 이더리움 전체 해시레이트와 연관이 있으며, 채굴에도 영향을 끼친다.
    - 현재 Ethash의 경우, 범용 GPU가 메모리 활용시 약 60%정도만 활용하기에 비효율적인데 반해 FPGA나 ASIC은 이런 비효율적인 메모리 활용을 임의설계하여 메모리 효율성을 높이기 때문에, 채굴 관점으로 보면 그 향상된 효율성이 곧 향상된 채산성으로 이어지게 되는 것이다.
    - 이에 ProgPow의 필요성이 대두되었고, ASIC의 향상된 효율성을 반감시키위하여, Ethash를 사용하면서도 상용GPU자원을 최대한 활용되도록 수정하는 것이 ProgPow의 디자인이다.
   < 회의 내용 >
    - (일전에 중단된) 감사가 진행되고 있고 8월말이나 9월초에 그 결과가 나온다. 우선 ProgPoW를 할경우 해시레이트 변동성과 같은 잠재적 문제들이 존재한다. 그리고 원래대로라면 이미 감사가 끝나고 검토까지 해야하지만 현재 상황을 보면 테스트넷HF를 할때까지 감사결과가 나오기 어렵다. 이런 이유들 때문에, ProgPoW를 이스탄불HF대신에 내년 4월에 있을 차기HF 또는 별도의 HF를 할때 추진하는게 나을수도 있다. 일단 감사결과가 나올때 이 개선안이 테스트넷에 포함될수 있는지 기다리기로 한다.

  ㅇ EIP-1962 : 보류
   < 부연 설명 > 자세한 내용은 여기글 후반부 참조
    - 타원 산술 및 런타임 정의와 결합에 대한 개선안으로, EIP-1829*에 대한 확장안이며 EIP-1109에서의 SATICCAL opcode보다 작업비용이 더 저렴하다.
    *  EIP-1829(https://eips.ethereum.org/EIPS/eip-1829) : 타원곡선선형조합에 대한 프리컴파일(Precompile for Elliptic Curve Linear Combinations)임. 이더리움 트랜잭션에 디지털 서명시, 송신자는 그 트랜잭션(거래)에 대한 진위를 수신자에게 확신시킬때 필요한 방정식이 있는데, 그것을 '사전에 컴파일링하는 방법에 대한 논의'라고 보면 됨.
   < 회의 내용 >
    - EIP-1962(https://eips.ethereum.org/EIPS/eip-1962)와 관련해서는, 각 오퍼레이션마다 서로 다른 프리컴파일을 호출해야하는 가에 대한 쟁점이 있다. 현재는 오퍼레이션마다 다른 프리컴파일을 호출하는데에 합의가 되었고 병렬처리도 현행유지(32)가 좋을것 같다는 의견이 있었다. 또한, 테스트넷HF까지 2주정도 남았는데 그 기한을 지키기는 어려울것같다. 우리는 이미 다른 (코딩) 언어로 2개의 실행결과물을 얻었고, 누군가 원하면 또다른 언어로 만들수도 있다. 중요한것은 프리컴파일에 대한 기준을 정하는건데, (이더리움2.0에서 가동될) 비콘체인을 위한 기준을 정한다면 (장기적으로도) 좋을것같다.
    - 일정을 따르는 것에 대해서는, 기한을 지키는 것은 중요하지만 현재 추진중인 EIP를 현행 로드맵에 적용했을때 시간이 충분한 것은 거의 없을것이다. 따라서 우선 가장 간단한 실행결과물을 성취하면서 추가적인 개선을 이어가는게 좋을것이다. 이스탄불HF의 주요 개선사항은, '체인ID', '가스비 감소'가 될것이며 '프리컴파일'도 마찬가지다.

  ㅇ테스트넷HF와 이스탄불HF 일정 관련 
    - 이스탄불HF의 주요 개선안들 중에서는 기존의 HF일정을 맞출수 있는게 있는 반면 맞출수있는지 가늠이 안되는게 있다. 따라서 우리에겐 2가지 선택지가 있으며, 하나는 HF일정을 지연시키는 것이고 다른 하나는 원래 HF일정을 무슨일이 있어도 키지는 것이다. 만약 또다른 선택지가 있다면 현행 HF일정을 지키되 새로운HF를 추가 진행하는것이다. 즉, 이스탄불HF이후 차기HF를 2020년 4월이 아닌 1월과 7월에 진행시키되 이스탄불HF때 부득이하게 추가하지 못한 EIP를 1월HF때 적용하는 것이다. 하지만 10월로 예정된 이스탄불HF이후 3개월만에 또다른 HF를 하는 것은 개발자의 개발진행으로나 클라이언트의 적응에 빡빡하다는 단점이 존재한다.
    - 우리가 특히 당장 걱정해야하는 것은 8월 중순에 예정되어있는 테스트넷HF다. 객관적으로 볼때, 예정대로 진행한다면 중요성이 떨어지는 EIP들만 적용될것이다. 따라서 최소한 테스트넷HF일정을 지연시키는게 바람직하며, 이스탄불HF는 가급적 원안대로 이행해보기로 한다.

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

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


□ 개인 논평

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

  ㅇ 이더리움과 라이트닝 네트워크
    - 지난 7월초에 부테린이 이더리움 네트워크 확장을 위해 비트코인캐시 블록체인을 사용하자는 제안이 있었다. 그런데 얼마 지나지 않아 최근에는 그는 트위터를 통하여 이더리움 스마트 컨트렉과 비트코인의 라이트닝 네트워크의 통합을 지지한다고 말했다. 이는 Blockade Games가 곧 출시할 이더리움 기반 RPG게임을 자체 테스트넷에서 통합을 전개한 것에 따른 것이다.
    - 아시다시피 라이트닝 네트워크는 비트코인의 오프체인 확장성 솔루션(Off-chain Scaling Solution)으로, 블록체인 바깥에서 사용자간 결제채널을 형성해 신속하고 수수료가 미비한 거래를 할수 있다 하여 제2레이어 결제 기술(The 2nd layer payment protocol)이라고도 한다. 7월만 보더라도 각 체인간 경계는 느슨해지고 있다. 본디 통합이라는 것은 각자의 장점을 취하고 단점을 보완하는 것이다. 본연의 정체성이 약간 훼손하더라고 그렇게 하는 이유는 블록체인 표준을 선점하는 것일수도 있고 블록체인 주도권을 잡기위해서 일수도 있다. 그 목적이 무엇이든간에 분명한것은 최우선 목적을 향한 개발은 수단과 방법을 가리지 않는다는 점이며 현재의 이더리움도 마찬가지이다. 그런의미에서 테스트넷HF, 이스탄불HF, 그리고 이더리움2.0을 앞둔 이더리움이 정체성유지와 지속된 향상의 적절한 균형(trade-off)를 잘 견지할수 있을지 우리는 꾸준히 지켜봐야할것이다.


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

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

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