[Ravencoin] Ravencoin Devs Meeting(19 July, 2019) // 7월 19일 레이븐 개발자 회의 분석 및 논평 v1.0

# Ravencoin Devs Meeting(19 July, 2019)



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

□ Analysis of the meeting by subject

  ㅇ Raven v2.4.0 Update 
    - The latest version of the Raven wallet was updated on July 8, fixing several bugs on a bitcoin-based codebase. Clients and users should update their wallet as soon as possible.

  ㅇ How to beat ASIC mining
    - Before telling about devs' meeting, let's look at the background knowledge related to ASIC resistance. According to the last survey, some people opposed the change of algorithm to resist ASIC. At first glance, these people don't seem to be wise, but perhaps they made a difficult choice. The reasons are as follows. If the algorithm is changed, since there are more than two chains to be mined in the process as the chain bifurcates, the mining hash rate, whether in the main chain or the fork chain, can be decreased, thus its network security is damaged. In addition, existing miners or the ones who newly start mining may not be able to mine changed algorithms, just watching the situation or for any other reasons. And its network security becomes weak again. In addition, if a hard-fork happens to change the algorithm, there may be a political power struggles, with the miners claiming that the branching chain, not the existing legacy chain, is the real main chain. The real problem is that all of these may be just a beginning of fighting against ASICs mining. Anyway, Raven was designed with x16r which has 16 subalgorithms randomly selected (in a certain way called the nibble) to prevent this troublesome ASICs mining. However, we have x21s that adds five more subalgorithms to the previous one and doesn't repeat the same subalgorithms consecutively unlike x16r(Footnote : in fact, this method was created when Raven was fork before). x21s seems better than x16r in some ways, because the r method has less power and GPU is more advantageous and and makes it more difficult to produce ASICs. If you go further, you'll get an x22s that has 22 sub-algorithms and is mixed with CNv4 (or CryptoNight R), which is Monero mining algorithm. In other words, 22 algorithms make it more resistant to ASICs, the s method makes GPUs more advantageous for mining, and makes it possible to arrange randomly in random order.
    - Tron Black (Tron Black, 'Tron' from now) presented an agenda called x22rc from the beginning of the meeting (Footnote : it means ASIC mining resistance is very urgent). He said he was more concerned about potential bifurcations than technical risks while looking at Moreno's multiple hard-forks. And he said that even in the process
of the branch, the asset issuer could protect the asset by choosing the most dominant chain, and is also concerned that Bitcoin bears BCH and BSV. Then, he asked other developers what it would be like to hear from the miners through BIP9*.
     * BIP9 : By generating multiple (soft) forks for adjusting the chain branch at the same time, the miners can send signals to make so-called 'bits voting'.
    - Other devs said that if there was no will, decentralization would be gone, and that the unknown 45% hash dominator** might not be ASIC miner, but FPGA miner, and that they don't know what the actual goal is to change the algorithm.
     ** Unknown 45% hash dominator : Since he first appeared in mid-January 2019 in Raven miningpool, his hashrate has been increasing, dominating 45% of its total hash in July. We just guess he has a lot of GPUs, or was now strongly suspected of ASIC miner.
< Evidence of unknown 45% hash dominator(https://medium.com/@nbitsdev/presenting-evidence-of-mining-centralization-on-the-ravencoin-network-88743db1910a) >

    - Tron said that devices with more hash at lower costs has nothing to do with network security, but would only damage decentralization(Footnote : dominating hashpower by economies of scale damage 'survival' or 'well-being' in the end).
    - Devs said adding more algorithms to x16r would be confusing, and that introducing CNv4 would bring CPU botnet issue.
    - Also, some devs said that when x16r was released in early 2018, it was new and innovative, but not anymore, and also said that the BIP9 method would be little meaningful because voting through BIP9 will be nothing if ASIC mining already is on.

  ㅇDevelopment Progress
    - Dividends function is being more tested for better security and there will be further news at the next meeting.


□ Personal Comment

  ㅇHow to deal with ASIC, Watch or Act
    - I have been watchng many devs meeting including Ethereum's but barely seen the meeting where devs much focus on one issue like this time(I have rarely put so many 'footnotes' to increase understanding like this time). It seems like an emergeny but we can happily see such an arguement of devs including the Tron, for more than an hour. Raven's willingness to protect its decentralization or identity that much.
    - For those who read only personal review part in my article, I would summarize like this : 'Whether Raven resist ASICs, and how?' The shadow of ASICs has already hung upon Raven community but there is no consensus yet. However, we just guess 'Raven will probably resist ASICs and it will go for changing algorithm which means Raven's way to fight against ASICs is Monero's way rather than Ethereum's. If you got some time, search for Monero's history of ASIC resistance. Monero's ASIC resistance struggle is
so desperate and still in progress.

  ㅇWhy now?
    - In my opinion, if ASIC resistance is a matter of 'survival' and the development is a matter of 'well-being'. Once we survive, then we can think about 'well-being' or 'well-dying,' so even devs put top priority on anti-ASICs and they should. Personally, it is very sad why we should discuss survival now that development is in full swing.
    - But ASIC Issue is a growing problem that our big crows will have to go through someday, if not now. As you know, Raven was born in bear market, and it is 'fate'. Who know? Its another fate is probably to find a good way to protect ASIC mining that any other projects never succeeded. Whether you support Raven or not, and whether it succeeds or fails, this challenge will be great in itself. I hope there will be some good results, and let me conclude my personal review with the sentence mentioned by one of the devs at this devs meeting. "It is up to the community".


(한국어 버전)

□ 소재별 회의 내용

  ㅇ 레이븐 v2.4.0 업데이트
    - 7월 8일 비트코인 기반의 코드베이스 상 몇가지 버그를 잡은 최신 버전 레이븐 지갑이 출시되었다. 클라이언트 등 사용자들은 빠른 시일내 업데이트하여 주시기 바란다.

  ㅇ ASIC 저항 방법 모색
    - 개발자 회의 내용을 다루기 전에, ASIC 저항과 관련한 배경지식에 대해 알아보자. 지난 설문조사를 보면 ASIC을 저항하기 위한 알고리듬 변경 제안에 반대한 사람들이 있었다. 얼핏보면, 이 사람들은 생각이 없어보이지만 어쩌면 이들이 어려운 선택을 했다고 볼수 있는데 그 이유는 이렇다. 만약 알고리듬을 변경하면, 체인 분기가 일어나면서 그 과정에서 채굴하려는 체인이 둘 이상이기에 메인체인이든 포크체인이든 채굴해시율이 빠질수밖에 없고, 따라서 네트워크 보안에 구멍이 생길수 있다. 거기에 기존 채굴자들이나 추가로 진입하는 채굴자들이 상황을 관망하든 아니면 다른 이유든, 변경된 알고리듬을 채굴하지 않을수도 있고 이때도 네트워크 보안이 취약해진다. 그뿐만 아니라 알고리듬 변경을 위한 하드포크가 실시되면, 채굴자들과는 별개로 기존 레거시 체인이 아닌 분기된 체인이 진짜 메인체인이라고 주장하는 세력이 나타나며 정치다툼이 발생할 수도 있다. 진짜 문제는 이 모든것이 하드포크 발생 초반에만 해당하는 사건들일수도 있다는 점이다. 아무튼 이런 골치아픈 ASIC 채굴을 막기위해 레이븐은 16개의 서브알고리듬을 (니블이라는 특정방식으로) 랜덤하게 선정되어 블록규칙과 체인규칙을 설계하였고 그것이 x16r이다. 그런데 여기에 5개의 서브 알고리듬을 더 추가함과 동시에 (x16r과 다르게) 매 블록마다 같은 서브알고리듬이 연속되지 않게 선택되도록 설계된 x21s가 있다(사실 이 방식은 레이븐이 포크되면서 생겨났다). x16r보다 x21s이 더 나은 점은, r방식이 s방식보다 전원공급시 전력편차가 적기 때문에 전력에 따른 조정에 쉬어져 GPU채굴이 보다 유리해지고, 5개 서브 알고리듬이 많아지기 때문에 ASIC 제작이 더욱 어려워진다. 여기서 더 나가면 x22s가 나온다. 이름에서처럼 22개의 서브 알고리듬이 존재하고 같은 서브 알고리듬이 두번이상 나오지않는 s방식이 탑재되면서 모네로 채굴 알고리듬인 CNv4(또는 CryptoNight R)을 섞었다. 즉, 22개의 알고리듬 덕분에 ASIC 내성이 강해지고 s방식이라 GPU채굴이 더 유리해지며, CNv4 덕분에 무작위로 정렬된 알고리듬이 무작위로 선택된다.
    - 트론 블랙(Tron Black, 이하 '트론')은 회의 초반부터 x22rc라는 안건을 제시하였다(필자주 : 그만큼 ASIC 채굴 저항이 더욱 중요해졌다는 의미). 트론은 모레노의 여러 하드포크를 보면서 기술적인 리스크보다는 잠재된 분기가 더욱 걱정이라고 말했다(필자주 : 하드포크시 체인이 분기되면서 더블 스펜딩, 리플레이 어텍 등의 기술적 결함이 발생하지만 그 보다는 체인이 분기됨으로써 오는 혼란성과 이해관계가 섞인 정치다툼이 더욱 걱정이라는 의미). 또한 그는, 체인 분기가 발생하더라도 레이븐의 경우 자산 발행자가 가장 지배력이 큰 체인을 선택하여 자산을 지킬수 있다고 말하면서도 비트코인이 BCH, BSV과 같은 중간급 이상의 브랜드를 파생시켰다는 점이 걱정이라고 말했다. 그러면서, BIP9*를 통해 채굴자들의 의견을 듣는건 어떤지 다른 개발자들에게 물었다.
     * BIP9 : 동시에 다수의 (소프트) 포크를 발생시켜 포크에 따른 체인분기를 조정하기 위한 방식으로, 이때 채굴자들은 신호(Signaling)를 보내어 소위 '비트방식의 투표(Bits voting)'를 할수 있음.
    - 다른 개발자들은 의지가 없다면 탈중앙성은 무너질거라고 말했고, 알려지지 않은 45% 해시 장악자**가 ASIC이 아닌 FPGA일수도 있다며 알고리듬 변경에 대한 근본적인 목표가 뭔지 모른다고 말했다.
     **알려지지 않은 45% 해시 장악자 : 레이븐 채굴풀에 2019년 1월 중순에 처음 등장한 이후, 2월 초부터 해시를 늘리면서 7월들어 레이븐 전체 해시의 45%를 장악한 알려지지 않은 자. 엄청 많은 GPU를 한데 모아 채굴할수도 있지만 현재는 ASIC채굴자로 강력히 의심받고 있음.
< 45% 해시 장악자의 흔적(https://medium.com/@nbitsdev/presenting-evidence-of-mining-centralization-on-the-ravencoin-network-88743db1910a) >

    - 트론은 더 적은 비용으로 더 많은 해시를 갖는 장치는 네트워크 보안에 전혀 도움이 되지 않으며 단지 탈중앙성을 해칠거라고 말했다(필자주 : 규모의 경제에 따른 해시 장악은 결국 '생존'에도 '웰빙'에도 도움이 되지 않는다는 의미).
    - 개발자들은 x16r에 알고리듬을 추가하는 것은 혼란만 가중될거라고 말했고, CNv4를 도입하면 CPU채굴이 늘어날텐데 그 경우 봇넷(필자주 : 컴퓨터 주인 몰래 그 컴퓨터를 사용하기 위해 심는 악성 소프트웨어를 의미)이 문제가 될수 있다고 말했다.
    - 또한, 2018년 초 x16r이 나올때만해도 그것은 새로운 것이고 혁신적이었는지는 몰라도 이제는 그렇지 않다는 의견도 있었고, BIP9를 통한 투표를 한다해도 ASIC채굴이 존재한다면 과반의 투표를 장악할수 있기 때문에 BIP9방식은 큰 의미가 없을 거라는 의견도 있었다.

  ㅇ개발 진행 상황
    - 보상(Dividend)은 더 나은 보안을 위하여 추가시험을 하고 있고 다음 회의때 추가 소식이 있을것이다.


□ 개인 논평

  ㅇ 품을 것인가 뱉을 것인다
    - 필자는 이더리움, 레이븐을 포함한 다양한 프로젝트의 개발자 회의를 지켜보면서 이번만큼 한 회의를 통째로 하나의 주제에 대해서 시간을 할애한 적을 거의 보지 못했다(추가로 이해도를 높이기 위한 '필자주'를 이렇게 많이 작성한 적도 없었다). 사실, 본문 내용에서 어려운 내용을 제외했지만 1시간이 넘는 동안 트론을 포함한 개발자들의 열띤 논의를 보자니 상황이 결코 좋지 않다. 주제넘게 공포 분위기를 조성하는 것은 아니지만, 탈중앙성을 지키고자 하는 레이븐의 의지가 그만큼 강하다는 것을 새삼 느꼈다.
    - 필자의 글에서 논평만 본다는 분들을 위해 본문내용을 요약하자면 'ASIC을 저항할것인가, 저항한다면 어떻게 할것인가'이다. ASIC 그림자는 이미 짙게 드리워졌지만 아직 이것에 대한 합의는 이뤄지지 않았다. 다만, 현재로서는 개발자들을 통해 '저항하긴 할텐데, 서브 알고리듬을 추가하는 방향으로 가겠구나'라고 예측할 뿐이다. ASIC저항의 선발주자들중에서는 GPU살리기 또는 무원칙을 고수한 '이더리움'방식보다 적극적 하드포크를 실시한 '모네로'방식을 택하겠다는 것이다. 시간이 된다면 모네로의 ASIC저항 역사를 검색해보시라. 모네로의 ASIC저항사투는 현재진행중이며, 끈질기다 못해 처절하기까지 하다.

  ㅇ 왜 하필 이 시점에..
    - 필자 생각에, 레이븐에게 있어 ASIC저항이 '생존'의 문제라면 개발상황은 '웰빙'의 문제다. 일단 '생존'을 해야 '웰빙'이든 '웰다잉'이든 할수 있으므로, 개발자들조차 생존을 먼저 챙기고 있고 또 그래야만 한다. 개인적으로 왜 하필 개발이 한창인 지금 생존을 논해야하는지 몹시 안타까울뿐이다.
    - 하지만 ASIC이슈는 굳이 지금이 아니더라도 우리의 큰 까마귀가 언젠가는 겪어야하는 성장통이다. 비트코인을 포함한 대부분의 토큰들이 위축한 하락장 속에서 태어난 그 운명처럼, ASIC에 속속 무너졌던 프로젝트들과는 달리 새로운 해법을 제시할 또다른 운명을 개척할것인가. 당신이 레이븐을 지지하든 지지하지 않든, 그리고 그게 성공하든 실패하든, 이 도전은 그 자체로 위대한 도전이 될것이다. 아무쪼록 좋은 결과가 있길 바라며, 이번 개발자 회의때 한 개발자가 언급한 문구로 개인 논평을 마무리하겠다. 'It is up to the community(커뮤니티에 달려 있다)'


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

[Fiction] Smells like Satoshi spirit 3부(5부작) // 사토시 영혼의 냄새가 나(3/5) v1.2

  죠셉은 두리번 거리며 집 주변을 둘러보았으나 아무도 없었다. 잠시 고민하다가 에라 모르겠다 싶어서 일단 그 서류봉투를 품에 넣고 집안으로 재빠르게 들어가 현관문을 걸어 잠궜다.
  뭔가 심상치 않은 서류임을 직감한 죠셉은 집안에 들어와서도 긴장을 늦추지 않고 자기 집 구석구석 몰래 들어온 흔적을 확인하기 시작했다. 모든게 있는 그대로임을 확인하고 자기 서재로 들어가서야 조금 안도하였다. 심호흡을 하며 정체불명의 서류봉투를 조심스럽게 열었다. 봉투속 서류 위쪽에는 최고급 기밀이 표시되어있었고, 딱 봐도 어마어마한 프로젝트에 대한 내용이라는 것을 알수 있었다.

 

'LUCY의 상품화와 그에 대한 윤리적 타탕성'
'LUCY의 잠재력과 그 한계'
'LUCY 프로젝트의 주최와 스폰서'

  죠셉은 주요 키워드들 위주로 빠르게 훑어보면서 떨리는 마음을 주체할 수 없었다. 이 떨림과 설레임은 사토시 스캔들 시절을 상기시켰고 뭔가 있다는 생각이 번뜩 들었다. 일단 불안한 마음에 뒷뜰에 설치한 비밀공간에 숨겨놓기로 했다. 비밀 서류의 내용을 상기시키면서 거실로 나왔다.
이게 하늘이 주신 또한번의 기회인지 아니면 끝없는 나락으로 떨어질 위기인지 가늠할수 없었지만 분명한것은 더이상 잃은것도 없는 그에게 이것은 하늘이 내린 기회이자 위기였다.

  긴장을 늦추지 않은채 며칠동안 외출을 하지 않으며 고민을 했고, 고심끝에 누군가를 찾아가기로 마음먹었다. 그러기전에 우선 죠셉은 기밀서류의 주요내용만 수기로 작성한 요약서를 만들기로 하고 바로 실행에 옮겼다. 자기가 아는 한 블록체인과 생명공학 등 혁신융합에 능통한 그 분이라면 믿고 조언을 구할수 있을거라고 생각했다. 찾아가기전에 미리 연락을 할까 하다가 일단 그분이 여전히 거기에 계속 사는지 확인할겸 그냥 찾아가기로 했다. 죠셉은 오랜만에 말끔한 옷차림을 하고 예전에 자주 들락날락한 그 분 집 앞에 섰다. 데이빗이라는 익숙한 이름을 발견한후 여전히 여기에 사는 걸 확인하자 안도감이 들었다.
  데이빗은 죠셉이 사토시 스캔들 특종을 낸 이후 알게된 분으로, 이후 언론 활동을 할때 관련 지식을 얻기위해 자주 자문을 요청했던 분이다. 한때 자주 만났지만 성공신화가 빛바래면서 그놈의 자존심때문에 한동안 연락을 못 했다. 그래서인지 집 앞을 서성거릴 뿐 문을 두드리기가 망설여졌다.

"자네 왔구만. 이게 얼마만인가?"

죠셉은 깜짝 놀라면서 뒤를 돌아보자 데이빗이 자기에게 걸어오고 있었다.

"아, 선생님, 연락없이 이렇게 갑자기 방문해서 죄송합니다. 잘 지내셨죠?? 하하"

죠셉은 멋쩍은 듯 웃으며 데이빗에게 인사를 건넸다.

"연락도 없이 자네가 온 걸 보니, 무슨 할말이 있는 게군. 일단 안으로 들어감세"

둘은 집 안으로 들어갔고 한동안 서로의 근황에 대해 대화를 나눴다.

"그래, 그렇게 지냈었구만. 그렇지 않아도 자네가 바쁘면 바쁜대로, 어려우면 어려운대로 연락이 없는 것 같아서 나도 굳이 자네에게 연락을 하지 않았네. 내가 자네 성격을 모르는 것도 아니고.. 어쨌든 지금이라도 이렇게 날 찾아오니 반갑고 좋네."

"자주 선생님에 대한 생각은 했지만, 그간 연락을 하지 못해 마음이 무거웠습니다. 죄송합니다."

"뭐, 사람사는게 다 그렇지. 때로는 가족도 자주 못보는데, 자기 마음처럼 그게 다 되나. 그건 그렇고, 날 찾아온 용건이 뭔가. 자네가 그냥 안부인사 묻자고 오는 사람은 아닐거고."

"하하. 먼저 말씀해주시니 질질 끌지 않고 바로 말씀드리겠습니다. 흠흠"

죠셉은 순간 긴장감이 들면서 목이 메었다.

"다름이 아니고, 며칠전 귀가하는데 집앞에서 의문의 서류를 발견했습니다. 현재까지 제 감과 판단으로는, 그 서류는 매우 비밀스러운 내용이 담겨있고 깊게 관여할수록 위험하지만 그만큼 기자로서 매력적인 소재라고 결론내렸습니다. 다만, 제가 전문적인 지식이 부족해서 그 내용이 이해하기 어려워서 선생님으로부터 자문을 구하려고 찾아뵜습니다."

"흠 그렇군."

데이빗은 놀라는 기색은 커녕 옅은 미소를 지으며 차 한모금을 마셨다.

"혹시 그 서류를 가져왔는가"

죠셉은 말없이 가방에서 요약서를 꺼냈고, 데이빗은 그것을 면밀히 살펴보고 입을 열었다.

"자네는 이 내용에 대해서 어느정도 이해했나?"

"정부주도로 비밀 프로젝트가 계획중인것까지는 알겠지만 세세하게는 이해하지 못했습니다. 그래서 이렇게 선생님께 이렇게 찾와왔구요."

"하나만 묻지. 자네는 이걸 그대로 덮을텐가, 아니면 위험하더라도 한번 파볼텐가"

죠셉은 선생님 역시 뭔가 느꼈음을 직감하고 망설임없이 대답했다.

"저 아시잖아요"

"그렇구만. 잘 알겠네. 일단 이건 나에게 맡기고 다음 만날때 더 얘기함세. 나 나름대로 좀 더 알아보고 얘기할 필요가 있어서 그러니 이해해주고"

"네 알겠습니다. 저도 굳이 서두르지 싶진 않습니다 하하"

죠셉은 데이빗이 즉답을 하지 않는 것을 예상했다는 듯 반응했다.

"선생님, 다시한번 연락 자주 못 드려 죄송합니다. 그럼 연락 기다리겠습니다"

"그래. 아, 혹시 다음에 만날때 그 원본 서류도 볼수 있을까?"

"아 네,, 알겠습니다. 갖고 오겠습니다"

몇 년만에 만난 그들은 조만간 만날것을 기약하며 헤어졌다. 그때 마침 헨리로부터 전화가 왔다.

"선배, 드릴 말씀이 있어서 그런데 선배 집으로 가도 돼요?"

"어, 안 그래도 지금 집에 가고 있어. 우리집에서 보자"

"그래요. 저번에 선배가 알려준 비밀번호 누르고 집 안에 들어가 있을게요"

"야, 그냥 집 앞에,,"

'뚜~ 뚜~'

  멋대로 끊어버린 헨리를 욕하며 죠셉은 차 시동을 걸었다. 지난번 만남에서 우울증 걸린 자기가 나쁜 생각을 할까 걱정하는 헨리에게 집 비밀번호를 알려준게 실수였다. 사실 죠셉은 자기 공간이 누군가에게 공개되는 것도 불쾌하지만 지금은 온 신경이 기밀서류에 쏠려있었기 때문에 더욱 불쾌해졌다. 당장 비밀번호를 바꿔야겠다는 다짐과 함께 재빨리 집으로 향했다.
  그런데 앞마당과 뒷뜰이 있는 2층 주택인 자기 집앞에 도착하자 헨리는 보이지 않았고 현관문은 살짝 열려있었다. 문도 제대로 잠구지 않고 먼저 들어간 헨리를 욕하며 집안으로 들어가려는 순간 뭔가 이상했다. 차 시동을 끄지 않은채 집에서 약간 멀리 차를 정차시키고 집으로 조금씩 향했다. 혹시 몰라 현관으로 바로 들어가지 않고 잠시 떨어져 집 창문들을 들여다봤는데 누군가의 실루엣이 비쳤고 무슨일이 벌어졌다는 강력한 확신이 들었다. 분명한 것은 그 실루엣이 후배의 것은 아니라는 점이다. 그리고 문득 뒷뜰에 숨겨둔 기밀서류가 생각났다. 그는 옆집을 끼고 크게 돌아서 자기집 뒷뜰로 향했고, 비밀공간 안에서 기밀서류를 포함한 총과 현금 뭉치들을 챙겨 다시 크게 돌아 자기차로 돌아가기로 했다.
  그런데 그 순간 자기 집 뒷뜰 한켠에 후배 헨리가 피를 흘린채 쓰려져 있는 걸 발견했다. 순간 심장이 덜컹하면서 후배를 흔들어 깨웠으나 아무 반응이 없었고 몸에 아무 힘이 없었다. 그때 뒷문을 통해 다가오는 누군가가 있어 살짝 몸을 숨겼고 곧 총을 든 두명의 사내가 눈에 띄었다. 분위기가 심상치 않음을 느낀 죠셉은 헨리에게는 미안하지만 이 현장을 벗어나기로 하고 조용히 몸을 숙인채 뒷마당을 빠져나왔다. 그리고 차를 몰아 시내로 향했다. 운전을 하면서도 자기가 겪고있는게 정말 현실인지 꿈인지 혼란스러움과 동시에, 자기가 죽을뻔 했다는 두려움보다 아끼는 후배가 죽었을수도 있다는 불안감이 들었다.



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

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

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

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

 ※ 모든 EIP는 해당EIP에 대한 참조 구현(코드)가 있거나 대변자가 성공적으로 필요성을 주장하는 한, 금번 회의에 이스탄불로 여정의 기로에 서 있을것입니다. 이스탄불로 가지 못하는 EIP는 차기 HF에 반영될수 있습니다.



□ 이스탄불 여정의 동행자 최종 후보

  ㅇ EIP-615(https://eips.ethereum.org/EIPS/eip-615) 
     - EVM을 위한 서브루틴(subroutines) 및 정적 점프(static jumps)다. '서브루틴과 연산기법을 도입하여 성능향상 등 검증의 최적화를 위한 작업'정도라고 보면 된다.
   < 부연 설명 > 자세한 내용은 여기글 후반부 참조
    - 블록체인은 자세한 설명과 검증이 필수인데, EVM*설계 상 그것들을 하기 어렵고, 낮은가스비 및 고성능실행 역시 적용이 어렵다. 현재 EVM은 동적 점프**(dynamic jump)를 지원하는데, 이경우 어디로 점프할지 스택상 명확하지 않다. 따라서, 정확성 증명, 정적 분석, 컴파일 최척화 등을 저해하는 동적 점프 사용을 지양하고, 이를 대체하기 위한 서브루틴과 몇가지 다른연산을 도입하고자 하며, 이를 통해 성능향상 등 이점을 제공하면서도, EVM성능한계를 시험할수
있을것이다.
     * EVM(Ethereum Vitrual Machine, 이더리움 가상 머신) : 이더리움을 전체를 작동하는 엔진으로, 수많은 토큰과 디앱 등을 책임짐.
     ** 점프(jump) : EVM의 컨트렉트 함수는 내외부, 재귀 호출 등 여러가지인데, 이 중에서 내부함수를 효율적으로 호출하는 연산코드로 프로그램 카운터(PC)를 이동하여 다른 바이트코드(bytecode)를 실행함.
     - 첨언하자면, 나중에 eWasm이 도입되겠지만 그럼에도 어쨌든 현재 가동중인 EVM을 개선될 필요가 있고 근본적으로 동적 점프를 제거할수는 없겠지만 대신에 정적점프를 사용하고 그덕분에 대부분의 언어로 사용자를 이동시킬수 있으며, 결국 이러한 EVM변경 덕분에 wasm으로 쉽게 이동(porting)도 가능할것이다. 이를 위해서, 서브루틴 추가, 정적점프 연산코드 추가, 커뮤니티 교육을 통한 동적점프 사용 빈도 낮추기 등이 필요할것이다.
   < 회의 내용 >
    - 현재로서는 EIP-615를 이스탄불HF에 적용하지는 않겠지만, 최종 적용여부를 위하여 추가 테스트를 할것이다.

  ㅇ EIP-1344 vs. EIP-1965 'EIP-1965와는 별개로 EIP-1344에 대한 (HF적용) 결정을 할수 있는가'
   < 부연 설명 >
    - EIP-1344(https://eips.ethereum.org/EIPS/eip-1344)은 컴파일링시 체인ID(서로 다른 체인간 트랜잭션 재생을 방지하는 수단)를 지정하고 opcode를 추가하면 그 체인ID에 접근하여 서명의 유효성을 검사하며, 따라서 다른 체인간 리플레이 어택 등을 방지할수 있다.
    -  EIP-1965(https://eips.ethereum.org/EIPS/eip-1965)은 체인ID가 특정 블록넘버에서 유효한지 확인하는 방법을 개선하는 것으로, 특정 체인ID가 특정 블록넘버에서 유효한지여부를 알려주는 프리컴파일을 추가한다.
   < 회의 내용 >
    - 정의, 실행 등에 대한 불확실성으로 인해 이스탄불HF 적용하지 않을 것이다.

  ㅇ EIP-1283(https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1283.md)
   < 부연 설명 >
    - 기존 콘스탄티노플HF에 적용될뻔한 EIP로, 총 가스 계량기(Net gas metering)를 변경하여 컨트렉트 저장소를 위한 새로운 활용가능성과 대부분의 작동방식이 맞지 않을때 발생하는 과도한 가스비의 감소를 목표로 한다. 한마디로, 불필요한 가스비를 줄이는 코딩을 가능케한다.
    - 참고로 EIP-1283는 완화제같은 역할을 하는 EIP-1706와 관련되어있는 기존 콘스탄티토플HF 적용 후보EIP로, 그때에 비해 큰 변화는 없으며 관련 개발자가 추가되었다. 다만, 이스탄불HF에 적용시 이 두 EIP(1706, 1283)가 결합되어 적용될지는 합의가 필요하나, EIP-1283이 이스탄불HF에 적용될지에 대해선 지난 HF에도 적용될수도 있었던 만큼 이미 준비가 되었다고 본다.
     * EIP-1706(https://eips.ethereum.org/EIPS/eip-1706) : 가스비가 집행비(Call stipend)보다 낮은경우 SSTORE사용을 불가능하게 하자는 제안.
   < 회의 내용 >
    - EIP-1283와 EIP-1706의 결합 등에 대한 일반적인 합의가 도출되지 않아 추가 논의를 하기로 한다.

  ㅇ EIP-1962(https://eips.ethereum.org/EIPS/eip-1962)
   < 부연 설명 > 자세한 내용은 여기글 후반부 참조
    - 타원 산술 및 런타임 정의와 결합에 대한 개선안으로, EIP-1829*에 대한 확장안이며 EIP-1109에서의 SATICCAL opcode보다 작업비용이 더 저렴하다.
    * EIP-1829(https://eips.ethereum.org/EIPS/eip-1829) : 타원곡선선형조합에 대한 프리컴파일(Precompile for Elliptic Curve Linear Combinations)임. 이더리움 트랜잭션에 디지털 서명시, 송신자는 그 트랜잭션(거래)에 대한 진위를 수신자에게 확신시킬때 필요한 방정식이 있는데, 그것을 '사전에 컴파일링하는 방법에 대한 논의'라고 보면 됨.
   < 회의 내용 >
    - HF적용 결정을 유보하고 온오프라인 상으로 추가 논의가 필요하다.

  ㅇ EIP-2028(https://eips.ethereum.org/EIPS/eip-2028)
   < 부연 설명 >
    - Calldata(이더리움 상에서 트랜잭션 요청시 전송 데이터가 저장되는 곳)의 가스비를 현행 바이트 당 68에서 더 감소시킨다. Calladata비용이 절감되면 잠재적으로 더 큰 블록이 생겨 네트워크 지연이 증가하지만, 수학적 모델링과 경험적 추정에 의해 네트워크 보안이 강해지고 확장성이 증가되는 부수적인 효과가 있을수도 있다.
   < 회의 내용 >
    - 이스탄불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방식 덕분에 더 효율적인 유효성 검증이 가능하며, 수수료가 발생하기에 중계자들은 중계하는 행위에 동기부여가 되며, 결국 이러한 과정을 통하여 비트코인을 사용하여 이더리움 어플리케이션을 실행할수 있다.
   < 회의 내용 >
    - 지난 63차 회의때 이미 이스탄불HF적용을 확정지었다.

  ㅇ 기타 다른 EIP 검토
   < State Rent 관련 EIP >
    - 아직 결정된것은 없지만 아마도 다음기회(어떤HF가 될지는 모르겠지만)를 노려야할것이다.
   < ProgPoW > EIP-1057(https://eips.ethereum.org/EIPS/eip-1057)
    - ProgPoW는 특정ASIC이 채굴할수 있는 작업유효간격을 좁히기 위해 고안된 PoW알고리듬으로, ASIC의 향상된 효율성을 반감시키위하여, 상용GPU자원을 최대한 활용되도록 수정하는 것이 ProgPow의 디자인이다.
   < 부연 설명 >
    - 우선 ProgPow는 ASIC채굴의 상대적 높은 효율성을 반감시키는 PoW변형알고리듬으로, AMD, NVIDIA 등이 제조하는 그래픽 카드에서 테스트되고 적용되며, 따라서 카드제조업체 및 산업에 적지않은 영향을 줄수 있고, 동시에 이더리움 전체 해시레이트와 연관이 있으며, 채굴에도 영향을 끼친다.
    - 현재 Ethash의 경우, 범용 GPU가 메모리 활용시 약 60%정도만 활용하기에 비효율적인데 반해 FPGA나 ASIC은 이런 비효율적인 메모리 활용을 임의설계하여 메모리 효율성을 높이기 때문에, 채굴 관점으로 보면 그 향상된 효율성이 곧 향상된 채산성으로 이어지게 되는 것이다.
    - 이에 ProgPow의 필요성이 대두되었고, ASIC의 향상된 효율성을 반감시키위하여, Ethash를 사용하면서도 상용GPU자원을 최대한 활용되도록 수정하는 것이 ProgPow의 디자인이다.
   < 회의 내용 >
    - (일전에 중단된) 감사가 재진행되기를 기다려야한다면, 일정상 이스탄불HF적용은 어려울것으로 보인다. 다만, ProgPoW만을 위한 'Single EIP HF'가 있을수 있으며 상황을 보며 논의를 이어가기로 한다.

  ㅇ 나머지 EIP는 이스탄불HF에서 제외되는가
    - 앞서 이스탄불HF 적용 확정여부를 결정한 것 이외에는, 참조 구현이나 대변자가 없으면 HF 미적용이며 추가논의가 필요한 EIP에 대해서는 다음 회의때 다루기로 한다.


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

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


□ 개인 논평

  ㅇ 이더리움 네트워크 개선 전략
    - 금번 개발자 회의에 대해서는 딱히 할말이 없기에 다른 관점으로 논평해보겠다. 예전부터 느낀거지만 이더리움 개발 회의, 커뮤니티, 각종 뉴스 등을 통해 현재 이더리움의 최우선 과제들 중 하나는 '확장성 높이기'다. 뭐 하루이틀 이슈된 것이 아니기 때문에 새로운 것도 없지만 이더리움의 개발 방향을 보면 최우선 과제들을 해결하려는 매일매일이 새롭고, 확장성 측면도 마찬가지다.
    - 이더리움2.0은 다양한 목표와 비전을 목표로 하고 있으며, 장기적으로 초당 10MB이상 데이터 처리가능한 데이터 레이어를 확보하는 '확장성 향상' 목표를 갖고 있다. 그런데 최근 이더리움 창시자 부테린은 한 게시물(보기 클릭)을 통해 단기적인 확장성 솔루션을 제안했다. 바로 비트코인캐시 블록체인을 이더리움 네트워크 확장을 위해 사용하자는
아이디어였다.
    - 비트코인캐시 블록체인 활용의 이점들은 다음과 같다. 첫째, 경제성이다. 이더리움 체인보다 비트코인캐시 체인이 거래수수료가 낮다. 둘째, 높은 데이터 처리가 가능하다. 초당 최대 8KB까지 데이터를 처리하는 이더리움에 반해, 비트코인캐시는 초당 약 53KB까지 처리가능하다. 셋째, 즉시 개시가능한 전략이다. 놀랍게도, 이미 이더리움 네트워크 안애서 비트코인캐시의 블록을 검증하는 기술적 준비가 완료되었다. 넷째, 비트코인캐시의 개방성이다. 거래수수료를 지불만 한다면 어디에 써도 용인하기 때문이다. 물론, 비트코인캐시의 블록시간이 10분이나 되기 때문에 근본적인 확장성 솔루션으로 보기에 무리가 있지만 제로컨펌기술 등을 통해 보완가능하기도 하고 단기적인 솔루션이기 때문에 필자가 봐도 나쁘지 않은 아이디어라고 생각한다.

  ㅇ 커뮤니티의 반응과 역할
    - 이러한 부테린의 아이디어에 대한 커뮤니티의 반응은 어떨까. 부정적인 의견이 많으며 개인적인 반응도 마찬가지다. 그 이유로, 혹자는 비트코인캐시에 대한 반감이 있어서 그렇다고 하지만, 개인적으로는 단기적인 이익을 위하여 굳이 그럴 필요까지 있냐라는 생각이 우선 든다. 차용하려는 블록체인이 비트코인캐시든 다른것이든 상관없이, '실험을 위한 실험'은 또다른 부작용을 낳기 때문이다. 이더리움2.0까지 가지 않더라도 이더리움의 지속가능한 확장성 향상은 결코 쉽지 않은 '실험'이다. 그런데 그 실험의 과정에 다른 블록체인을 단기적인 이익을 위하여 '실험'의 '실험'을 한다는 것은 필자가 볼때 쉽게 납득이 되지 않는다. 불과 몇달전만 하더라도 단기 확장성 향상을 위하여 영지식증명을 활용한 온체인 확작성 솔루션이 소개되었다. 그 아이디어에 대해서는 긍정적이다. 왜냐면 익명성 기술은 확장성 외에도 개인정보보호 등 다른 이점들도 존재하고, 지속가능하며, 커뮤니티도 납득가능하기 때문이다.
    - 비트코인캐시 블록체인 활용 아이디어가 아직 공식적으로 확정도 안 된 마당에, 벌써부터 딴지를 걸고 싶은 마음은 아니지만 이더리움 측은 어떤 아이디어라도 개발자와 커뮤니티의 반응과 소통을 통해 지속가능하면서도 가장 많이 용인하는 방향으로 나아가기를 바란다. 따라서 그 과정에서 우리들 역시 지지든 비판이든 목소리를 내는 역할을 하는 것이 매우 중요하다. 


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

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

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