[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)를 잘 견지할수 있을지 우리는 꾸준히 지켜봐야할것이다.


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

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


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


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

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



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

□ Analysis of the meeting by subject

  ㅇ C++ Developer Recruitment
    - Early in the meeting, Tron Black(Tron) said we are looking for a C++ dev to help out the core team. We would prefer them to be in the Utah office, but would consider remote for the right person.
     ※ In the current state of development of Raven, developers who are in charge of each function were sick or not be reached, which is harmful to its development. Therefore, hiring developers who are able to cantact at any time and work together would not to delay the roadmap schedule any longer.

  ㅇStory of DEX built by Bruce penton
    - A dev said, "I heard Bruce is buildinga DEX," and asked if it is ture. Tron responded he hadn't heard of it saying he deosn't know when, but it would be great if we had a DEX for Raven Coin. The dev who asked said Bruce on Feb 28, 2019, left a message saying, 'I’m looking for people to help build a DEX'.

  ㅇDevelopment progress
    - A dev asked about the progress of the development of features, and Tron said they are going well according to the road map, and that all functions were active on testnet. In particular, we expect Memo* to increase IPFS hash according to all transactions.
     * Memo is an immutable property associated with all transactions stored in IPFS by the messaging function. Once the messaging and memo function is completely tested, IPFS will be combined with IPFS and the IPFS where the data is stored will be activated with messaging and memos, then the IPFS hash will naturally added.

  ㅇ Tags and Restricted Assets
    - Before the devs discuss, I will explain the background of the tags and restricted assets. First, anyone can be an issuer that uses Raven network to register assets, but ownership of assets requires a certain amount of Raven, the name of the asset to register, and tags. For example, creating general unique assets(non-restricted assets) requires 500 ravencoin and the asset name must be unique. In addition, 1,500 raven is required to generate restricted assets, and it is expressed like $ABC, and can only be transferred with tagged addresses beginning with something like #. To preven confusion in the future, General unique assets(e.g., ABC) and restricted assets($ABC) should be different in terms of naming. Therefore, if someone wants to purchase and register restricted assets, a system may be built to register non-restricted assets first. In other words, it is kinda 'a package'.
    - (Back to the devs meeting) Tron said that only an issuer of the asset could freeze the restricted asset, and that it would cost a fee to burn tags and restricted assets. However, tags that serve as logical operations (and, or not) will not function as such rather than as burned. Anyway, the person who can get rid of tags is the token issuer related with the tag.
    - They also said that restricted assets of the same name (for example, $BALL) can be created only if someone has unique assets, or restricted assets(for example, BALL). Note that the cost of creating a restricted asset is 1500 ravencoin.

  ㅇ About anti-ASIC
    - Tron said that while custom hardware itself (such as ASIC) is not bad, such equipment causes centralization. As Raven devs, we are against ASIC, so those involved in ASIC will invade in secret.
    - Then Tron said, "The first stepis to mine Raven with CPU, the second stage to mine by GPUs, the third stage to have GPUs as well as FPGAs, the fourth stage to have GPUs, FPGAs, and a few ASIC, and the fifth stage predominantly ASICs. Tron said that we are now at 3, and some said at 4.
    - There are cases of botnet(malicious software planted to use someone's computer), but it is a matter of individuals and does not damage decentalization.
    - In addition, since making asics is hugely R&D and cost intensive so minor changes can ruin asics with designs currently in production, minor changes in algorithms can ruin ASIC mining. However, the sudden change in the algorithm can cause confusion among GPU miners and eventually affect network security. After all, minimal changes are best, but a big change is still good for anti-ASIC.


□ Personal review

  ㅇ Voice of Raven Community on ASIC
    - I introduced on previous personal review the survey on Raven(https://www.surveymonkey.com/r/W29S96N) and its results were released. Let's take a closer look at the results as it is as important as the Raven development.
    - First of all, it is about the type of Raven participation. Miners account for the largest portion, followed by owners. Even considering investors, there are more non-miners(holders, investors) than miners.
    - Second, it is about how many GPUs are mining Raven(only for miners). A majority of the respondents said they mine fewer than a dozen GPUs, while more than 10 percent said they mine with more than 50 GPUs.
    - Third, it is about whether they were in favor of ASICs, and an overwhelming majority of respondents said they were against ASICs.
    - Fourth, it is about whether you think the algorithm is worth changing (for ASIC resistance) even if Ravencoin chain is bifurcated and possibly exists as multiple chains. Various opinions were expressed in response. First of all, those in favor of changing the algorithm said thes: The reason why we supported Raven in the first place is that even individuals can mine then, and if ASIC is on, we, early supporters, feel abandoned. Also, Raven was designed from the beginnning with several sub-algorithms for ASIC resistance, we will lose Raven's identity if let ASIC dominates. On the other hand, opponents of the algorithm change said : If we have to change the algorithm to resist ASIC but have chances to have multi-chains, Raven project will have to choose. to be nor not to be.. And what's more important than ASIC is network security, not to achive decentalization, and if network security is destroyed, we will support ASIC mining rather than splitting its chain.
    - Fifth, it is about the question is what strategy should be established if ASIC mining is detected. The most popular strategy was to change the mining algorithm every six month, as was Monero's. The second most popular strategy was to (immediately) change the mining algorithm, and the third was to completely change it to GPU-specific algorithms like Ethereum's ProgPoW method.
    - Last sixtth, it is about whether ASIC mining was already in progress. While most of them answered that ASIC mining is not in progress, some believe that it is true through some analysis and showing some opinions.

  ㅇ Personal opinion about ASIC
    - I have monitored how Monero and Ethereum responded to ASIC's resistance. As for Raven, I guessed what strategy Raven will set to anti ASICs.
    - First of all, security of the network is the top priority, regardless of coin types. No matter how important ASIC resistance is, it cannot be as important as network survival. In order to survive the network, Monero set a strategy to change the mining algorithm every six month, and Ethereum is considering introducing a GPU-specific algorithm(ProgPoW) but has kinda 'no-strategy' that does not set any significant
strategy to date.
    - Looking at current trends, I think Raven is more likely to follow the Monero way and the reasons for this are as follows. First, devs including Tron are monitoring Monero's strategy. Second, Raven needs a strong rstrategy as it is designed to be inherently strong in ASIC resistance. Third, in a recent survey, the community also wants to change the algorithm. The problem is 'When ASICs invade' and we just hope to respond to ASICs after major functions such as tags, messaging, restricted assets and voting are activated on mainnet. Hopefully, Raven's devs and community will come up with a unified stance on ASIC resistance before too late.


(한국어)

□ 소재별 회의 내용

  ㅇ C++개발자 모집
    - 회의 초반에 트론 블랙(이하 'Tron')은 레이븐 핵심 개발팀에 합류할 C++개발자를 구하고 있다고 밝혔다. 조건은 유타 사무실에 근무가능한 개발자를 우선 고려하겠지만, 떨어져있어도 적합한 인물이라면 고려해보겠다고 말했다.
     ※ 필자주 : 레이븐 개발현황을 보면 동시다발적으로 여러 기능을 테스트중인데, 각 기능을 전담하는 개발자들이 종종 아프거나 연락이 닿지 않아 개발진행에 해가 되는 경우가 몇번 있었다. 이에 상시 근무하면서 즉시 소통가능한 개발자를 채용하는 것이 개발일정이 더이상 늦춰지지 않기 위한 일환으로 보여짐.

  ㅇ 브루스펜튼의 DEX 제작설
    - 한 개발자가 브루스펜튼(이하 'Bruce')이 DEX(탈중앙거래소)를 만든다는 애기를 들었다며 혹시 진행상황이 어떤지 물었다. Tron은 들은바가 없다면서, 그게 언제인지는 모르지만 레이븐코인을 위한 DEX가 생긴다면 참 좋을 것이라고 말했다. 질문한 개발자는 2019년 2월 28일에 Bruce가 'DEX를 만드는데 도움을 줄 사람을 찾는다'라는 메시지를 남겼다고 말했다.

  ㅇ 개발진행상황
    - 한 개발자가 레이븐 관련 기능들에 대한 개발진행상황을 물었고, Tron은 로드맵에 따른 순서대로 잘 진행되고 있으며, 모든 기능들이 테스트넷에 활성화되어있다고 말했다. 특히 메모*가 모든 트랜잭션에 따라 IPFS해시를 늘릴것으로 기대한다고 말했다.
     * 메모(Memos)는 메시징 기능에 의해 IPFS에 저장된 모든 트랜잭션과 연결되는 변경 불가능한 속성으로 메시징기능과 메모기능의 테스트가 완료되면, IPFS와 결합될것이고 데이터가 저장되는 IPFS가 메시징 및 메모와 함께 활성화되면 IPFS해시도 자연스럽게 늘어남.

  ㅇ 태그(Tags)와 제한자산(Restricted Assets)
    - 개발자들의 논의에 앞서 태그제한자산에 대한 배경지식을 설명하겠다. 우선, 조건만 맞츠면 누구든지 레이븐 네트워크를 활용하여 자산을 등록하는 발급자가 될수 있지만 특정 자산의 소유권을 갖기위해서는 일정량의 레이븐과 등록하고자 하는 자산명, 그리고 태그적용이 필요하다. 가령, 일반 고유자산(제한자산 아님)을 생성하기 위해서는 500레이븐이 필요하고, 자산명은 중복되지 않는 독창적이어야한다. 그리고 제한자산(Restricted assets)을 생성하기 위해서는 1,500레이븐이 필요하고, 태그로 표현하면, $로 시작(예 : $ABC)하며, # 등 태그된 주소로만 전달이 가능하다. 향후 증권토큰 대비하여, 일반고유자산(예 : ABC)과 제한자산($ABC)를 서로 다른 주체가 보유하지 않고 하나의 주체가 보유하도록 설계하여 네이밍 측면에서 자산 소유권에 혼란을 방지하자는 것이다. 따라서, 누군가 제한자산을 구매등록하고싶으면 비(非)제한자산인 일반고유자산을 우선구매 등록하는 시스템을 구축될수도 있다. '일종의 패키지'인 셈이다.
    - (다시 개발자 회의로 돌아와서) Tron은 오로지 자산 발행자(issuer)만이 제한자산을 동결시킬수 있다고 말했고, 태그와 제한자산을 소각하는데 수수료가 든다고 말했다. 다만, 논리적 연산(and, or, not) 역할을 하는 태그의 경우 소각된다기 보다는 그 논리적 연산 역할을 못 하게 될것이라고 말했다. 어쨌든 태그를 없앨수 있는 사람은 그 태그와 관련된 토큰 발행자다.
    - 또한, 어느 누군가가 고유자산, 즉 비(非) 제한자산(예: BALL)을 갖고있는 경우에만 동일한 이름의 제한자산(예: $BALL)을 생성할수 있다고 말했다. 참고로 제한자산을 생성하는데 비용은 1500레이븐이다.

  ㅇ ASIC에 대하여
    - Tron은 (ASIC과 같은) 주문제작형 하드웨어 자체가 나쁘진 않지만 그런 장비는 중앙화를 야기한다고 말했다. 레이븐 개발자로써, 우리는 ASIC에 저항하는 입장을 갖고있으며, 따라서 ASIC 관련자들은 비밀리에 (레이븐을 채굴하기 위한) 계획을 짤 것이다.
    - 그러면서 Tron은 (채굴의 탈중앙 단계를 나열하면서) 1단계는 누구든지 컴퓨터 CPU로 레이븐을 채굴하는 것이고, 2단계는 일반적으로 사용하는 GPU로 채굴하는 것이고, 3단계는 GPU뿐만 아니라 FPGA까지 채굴에 가세하는 것이며, 4단계는 GPU와 FPGA, 그리고 약간의 ASIC채굴기가 진입하는 것이고, 마지막 5단계는 ASIC채굴기가 채굴을 장악하는 것이라고 말했다. Tron 본인이 볼때, 우리는 현재 3단계에 있으며, 혹자는 4단계에 진입했다고 말했다.
    - CPU채굴 중에서는 봇넷(컴퓨터 주인 몰래 그 컴퓨터를 사용하기 위해 심는 악성 소프트웨어)에 의한 사례들이 있지만 그것은 단지 개인차원의 문제일뿐 탈중앙성을 훼손시키지 않는 문제이기에 크게 신경쓰지 않서도 된다고 했다.
    - 또한, 특정 코인을 타킷으로 하는 ASIC을 제작하기 위해서는 상당한 연구개발과 예산이 투입되기 때문에, 약간의 알고리듬 변경으로도 ASIC제작 계획 자체를 무기력하게 만들수 있다고 말했다. 다만, 알고리듬 변경시 갑작스러운 변경은 GPU채굴자들에게 혼란을 주고 결국 네트워크 보안에도 영향을 끼칠수 있다고 말했다. 결국 최소한의 변경이 가장 좋지만, 많은 변경은 혼란을 가중하는 대신 아식 저항성을 높일수 있는 이점이 있다고 말했다.


□ 개인 논평

  ㅇ ASIC에 대한 레이븐 커뮤니티의 목소리
    - 지난 레이븐 회의 분석 및 논평 글에서 안내한 설문조사(https://www.surveymonkey.com/r/W29S96N) 결과가 나왔다. 레이븐 개발만큼 중요한 사안이기에 그 결과를 세부적으로 살펴보자.
    - 첫번째로, 레이븐 참여유형에 관해서다. 채굴자가 가장 많은 비중을 차지하고 있으며 근소한 차이로 보유자가 그 뒤를 따랐다. 투자자까지 감안한다면, 채굴자보다 비채굴자(보유자, 투자자)가 더 많다고 볼수 있다.



    - 두번째로, 채굴자에 한하여 몇개의 GPU로 레이븐을 채굴하는지에 대한 질문이다. 과반수가 12개 미만의 GPU로 채굴한다고 응답했고, 50개 이상의 GPU로 채굴한다는 사람들은 10%가 넘었다.


    - 세번째로, ASIC채굴에 대하여 찬성하는지에 대한 질문으로, 압도적으로 많은 응답자들이 ASIC채굴에 반대한다고 응답하였다.


    - 네번째로, 레이븐코인 체인이 분기되고 여러 체인으로 존재할 가능성이 있다해도 (ASIC 저항을 위해) 알고리듬을 변경할 가치가 있다고 보는가에 대한 질문이다. 서술식 응답으로 다양한 의견들이 나왔다. 우선 알고리듬 변경에 찬성하는 사람들은 이렇게 말했다. 애초에 레이븐을 지지한 이유가 평범한 개인들도 채굴이 가능하다는 점인데 ASIC채굴을 그냥 둬버리면 초기 지지자이자 대부분의 채굴자들을 저버리는 것이다. 그리고 개인 채굴자들을 떠나서, 처음부터 ASIC저항을 위해 여러개의 서브 알고리듬을 설계한 것인데, ASIC채굴을 그냥 내버려둔다면 레이븐 정체성을 잃는 것이다. 반면, 알고리듬 변경에 반대하는 사람들은 이렇게 말했다. ASIC을 저항하기 위해 알고리듬 변경을 해야하지만 수많은 체인으로 쪼개진다면 레이븐 프로젝트는 존폐의 길에 들어설것이다. 그리고 ASIC보다 중요한 것은 탈중앙성을 지키는 것이 아닌 네트워크 보안인데, 네트워크 보안이 붕괴되지 않는다면, 체인이 쪼개지는 것보다 ASIC채굴을 완화하는 방향을 지지할것이다.

    - 다섯번째로, ASIC채굴이 감지될경우, 어떤 전략을 세워야하는지에 대한 질문이다. 가장 많은 지지를 받은 전략은, 모네로의 전략처럼 채굴 알고리듬을 6개월마다 변경하는 전략이었다. 두번째로 많은 지지를 받은 전략은, 채굴 알고리듬을 즉시 바꾸는 전략이었고, 세번째로 많은 지지를 받은 전략은, 이더리움의 ProgPoW방식처럼 GPU에 특화된 알고리듬으로 완전히 바꾸자는 전략이었다.

    - 마지막 여섯번째로, ASIC채굴이 이미 진행중인지 묻는 질문이었다. 대부분 ASIC채굴이 진행중이지 않다는 답변을 한 가운데, 일부는 넷해시가 확 올랐다, 어떤 분석을 통해 ASIC이 있다고 믿고있다 등의 의견을 냈다.

  ㅇ 개인적인 ASIC에 대한 고찰
    - 필자는 모네로와 이더리움이 ASIC을 저항하기 위해 어떻게 대응했는지 지켜봤다. 레이븐에 대해서도, 레이븐 개발자 회의와 앞서 언급한 설문조사를 토대로 어떤 대응전략을 세울것인지 추측해봤다.
    - 우선, 코인 종류를 막론하고 최우선순위는 '네트워크의 보안'이다. ASIC저항이 아무리 중요해도 네트워크 생존만큼 중요할수가 없다. 그 네트워크 생존을 위해서, 모네로는 주기적으로 채굴 알고리듬을 변경하는 전략을 세웠고, 이더리움은 GPU에 특화된 알고리듬(ProgPoW) 도입을 검토중이지만 현재까지 이렇다할 전략을 세우지 않는 사실상의 '무전략'을 세우고 있다.
    - 현재 추이로 보면, 필자 생각에 레이븐은 '모네로 방식'을 따를 가능성이 좀 더 높으며 그 이유는 다음과 같다. 첫째, 트론을 포함한 개발자들이 모네로 전략을 주시하고 있기 때문이다. 둘째 레이븐은 태생적으로 강력한 ASIC 저항성을 갖도록 설계되어있는만큼 강력한 대응전략을 세울것이기 때문이다. 셋째, 최근 설문조사를 통해 커뮤니티의 여론도 알고리듬 변경을 대부분 원하고 있기 때문이다. 문제는 '본격적인 ASIC채굴 도입이 언제냐'인데, 제발 태그, 메시징, 제한자산, 투표 등 주요 기능들이 메인넷에서 활성화되고 난 이후에 ASIC을 대응하기만을 바랄뿐이다. 그때까지 개발자들과 커뮤니티가 ASIC저항에 대하여 통일된 입장을 내놓기를 바란다.


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

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

  죠셉의 입에서 탄식하듯 내뱉은 '사토시 스캔들'은, 유명한 블록체인개발자를 시작으로 자신이 사토시 나카모토라고 주장하는 자들이 하나둘씩 살해를 당한 연쇄살인사건과 관련되어있다. 살인 방식이 잔인하기도 했지만 살인현장이 미국, 중국, 유럽 등 한곳에 모여있지 않고 '분산'되어있었다. 이에 암호화폐 투자자들은 왠지모르게 열광한 반면, 국가의 수사기관은 연속된 살인에 무기력함을 스스로 드러내자, 곧바로 전세계적인 공조를 벌여 추적을 하기 시작하였다. 같은 시기에 죠셉은 특유의 동물적인 감각과 집요한 조사 덕분에 살인범을 '진짜 사토시'로 지목하고 입증하는 쾌거를 이뤘고, 그때 당시 냈던 특종기사가 아침에 방바닥에 나뒹군 기사였다.


  그 특종 덕분에 죠셉은 일약 스타 언론인이 됨은 물론, 등록관청에 개인토큰을 등록하자마자 기준토큰-개인토큰환율이 급등하였고 자신의 이름을 건 1인 미디어사까지 설립하여 유명언론인으로 이름을 날렸다.
  하지만 전세계적으로 공조한 수사기관들이 사건해결은 커녕 스캔들의 들러리로 전락해버리자, 수사와 관련된 국가들의 정부와 당국은 오히려 죠셉을 깍아내렸고 심지어 그를 연쇄살인범 누명을 씌웠다. 죠셉이 인기와 핍박에 천국과 지옥을 한창 오갈때쯤, 합동수사 당국은 연쇄살인범으로 추정되는 자의 위치를 파악하여 포위망을 좁혀갔고, 결국 용의자는 비트코인이 100만개 담긴 사토시 지갑의 프라이빗키를 적은 유서를 남기고 자살했다. 그렇게 세기의 스캔들은 일단락 되었고 죠셉은 누명이 벗겨짐과 동시에 한동안 이슈메이커로 남았다. 비트코인은 그 스캔들 이후로 역대 최고점을 향한 마지막 상승랠리를 기록하였다.

  "그때부터였지, 비트코인이 마지막 힘을 다한게,,,"

  "네? 방금 뭐라고 했어요?"

  "아냐, 별거 아니다. 다 먹었으면 나가자"

  죠셉은 답답한듯 후배와 함께 밖으로 나섰다.

  연이틀 후배와 지적 공유의 시간을 지내고 나서 무료한 나날을 보내던 죠셉은 자주 가는 바에 들러 자기가 좋아하는 자리에 자기가 좋아하는 노래를 신청해 들었다. 그렇게 멍 때리는 것도 잠시, 다시 잡념이 그의 머릿속을 지배하기 시작했다. 인정하기 싫었지만, 그놈의 자존심때문에 자신이 씹다뱉은 껌 취급 받는게 죽기보다 싫었다. 더 짜증나는건 죠셉 본인의 개인토큰환율이 야금야금 하락하는 것을 지켜볼수밖에는 현실이다.
  개인토큰제도(Individual token sysyem)가 생긴건 오래되지 않았지만, 있는 자들 위주로 수요가 폭발하면서 하나의 글로벌 트렌드가 되었다. 현재는 국가별로 본격적인 토큰경제시스템이 도입되면서 금융당국의 심사를 통해 영향력있는 인물들부터 국가토큰과 연동되는 개인토큰을 만들수 있었고 이 개인토큰들은 국가토큰과 실시간 환율대로 가치가 매겨졌다. 국가토큰은 해당 국가의 근로자 보수의 중간값을 기준으로 하기에 환율이 1보다 높으면 중산층 이상을 의미하고 1보다 낮으면 경제적으로 여유가 없는 것을 의미한다. 여기에 당국의 규정을 준수하면, 그 개인토큰을 기반으로 스테이킹, 대출, 배당 등 다양한 비지니스 모델을 구축할수 있다. 그야말로 개개인이 하나의 작은 경제주체가 되었고 영향력이 큰 개인이나 법인들은 하나의 은행이나 금융시스템에 버금가는 시대가 온것이다.

  '0.65382139'

  죠셉의 스마트 와치 화면에서 그의 개인토큰환율이 깜빡였다. 특종기사로 이름을 날린 이후에는 이보다 10배가 넘었지만 현실은 가혹했다. 그럼에도 불구하고, 근근히 삶을 버티는 이유는 언젠가는 커리어로든 경제적으로든 또다른 대박을 터뜨릴수있다는 실낱같은 희망과 헨리같이 자기를 응원하는 사람들이 있기 때문이다.

  대학 후배인 헨리는, 유명한 사업가가 조직한 탈중앙화 자율조직(Decentralized Autonomous Organization, DAO)에서 인플루언서로 활동하고 있다. 사람들이 과거에는 한 국가의 국민으로서 정체성을 가졌다면, 현재는 그 뿐 아니라 각자가 속하는 토큰 커뮤니티로부터 또다른 정체성을 갖게되었다. 참여자들은 같은 커뮤니티라는 동질감을 느끼면서도 국적, 종교 등과는 별개로 사회적 활동을 하기도 하고, 특히 토큰에 기반한 경제적 소비활동도 하고 있다.

  죠셉은 갑자기 헨리가 보고싶었지만 이번만큼은 자신만의 시간을 갖기로 했다. 그런 의미에서 그는 쪼그라들대로 쪼그라든 자존심을 애써 외면하면서, 오랜만에 칼럼 하나를 작성하기 위해  가방에서 노트북을 꺼냈다. 살짝 취기가 올라와서일까, 왠지 무거운 주제를 다루고 싶은 생각이 들었다.


「가명성과 익명성이 낳은 현금으로의 회귀, 우연인가 필연인가」 

  2009년 초 등장한 비트코인은 '가명성'이라는 가면 덕분에, 거래 참여자가 누구라고 특정지을수 없지만 분산원장을 통해 추적이 가능한 암호화폐의 길이 열렸다. 하지만 그 '가명성'은 시간이 지나면서 인간의 본능에 가까운 개인정보보호욕구를 자극하면서 '익명성'으로 진화하였고, 결국엔 발달된 전산암호학과 거대한 토큰경제가 결합되어 누구나 갖고싶어했던 스위스계좌가 개개인의 디지털 지갑속까지 들어간듯한 시대가 도래하였다. 그러나 아무리 익명거래를 한다해도 기술적 결함이 발생되거나 중앙화거래소를 이용하는 순간, 그 익명성이 해제되면서 거래내역이 노출될 수 있다.
  한편, 거래 추적 불가능은 없을것이라는 정부는 철저한 추적 시스템을 구축하여 토큰세상을 여는 마스터키를 확보했다고 판단하였다. 하지만 그 판단과는 반대로 토큰경제가 전 세대의 일상속에 상당히 스며들때쯤, 익명성기술을 탑재한 토큰체제 큰 문제없이 토큰경제의 효용성을 세상에 전파하였고, 장기간 연구와 모니터링을 해온 주요 국가들은 통제불가능한 익명성과 토큰경제체제를 그대로 놔뒀다가는 기존 기득권에 득보단 독이 될거라고 결론내리고 견제하기로 마음먹는다. 이 사활을 건 견제는 의외의 파장을 일으키는데, 바로 구세대와 신세대간 갈등이다.



  아직까지 현금이 익숙한 구세대는 정부에 대한 반발과 익숙함 때문에 그에 대한 반발로 현금으로의 회귀를 시작했고, 태어날때부터 토큰이 곧 일상화폐라고 인식한 신세대는 그런 구세대를 조롱하며 정부가 견제할수록 토큰을 더욱 사용하였다. 그런데 그때쯤 우연찮게 익명성 프로토콜의 치명적인 결함이 발생하였고 비슷한 시기에 비트코인을 포함한 암호화폐의 최대 거품이 빠지자 일대 혼란이 일어난다. 결론적으로, 안전하고 투명하면서도 개인정보를 보호할수 있으리다 여겼던 '가명성'과 '익명성'에 기인한 탈중앙화 토큰에 대한 신뢰와 지지에 균열이 생겼고, 그나마 브랜드가치가 높았던 주요 암호화폐들은 살아남아 무정부주의자들의 자산보존수단으로 전락해버렸다. 그와 동시에 주요 국가들은 기다렸다는듯이 국가토큰경제시스템을 속속 도입하여 혼란스러운 경제시스템에 믿을수 있는 자산은 국가토큰뿐이라며 선전과 홍보에 열을 올렸고, 일상속 토큰은 물론 익명성 토큰 역시 정부주도로 기술개발되고 있는 현재에 이르렀다. 이 모든 과정에서 일어난 의심스러운 사건과 사고들이 생긴 것은 단순 우연인걸까 아니면 언젠간 일어났을 필연적인 걸까.


  간만에 칼럼작성이 힘들었는지 아니면 취기가 확 올랐는지 집중력이 흐트려졌고, 탈고는 나중에 하기로 하고 계산을 마치고 바를 나섰다. 금요일 밤인지 밤거리에는 사람들이 많았고, 죠셉은 인파속을 지나 집으로 성큼성큼 향했다. 이제는 인파 속 사람들 중 누구도 그를 알아보지 못하지만 그는 여전히 그 당시의 본인과 대중을 기억한다. 사토시 스캔들 이후, 대중은 죠셉에게 더 자극적이고 음모론적인 가십성 기사를 기대하였고, 그는 자신의 뜻대로 올곧게 미디어활동을 하는 이상과는 달리, 대중에게 잊혀지지 않기 위해 본능적으로 관심끌기용 기사들을 쏟아내기 시작하였다.
  그게 잘못된 판단이었을까. 암호화폐의 거품이 빠지고 나자 그의 전성기 역시 하락세를 면치 못했다. 과거 존재했던 수많은 토큰들처럼 죠셉 역시 지속가능한 매력을 보여주지 못한 탓에 본인의 가치가 떨어진 셈이다. 그래도 오늘 밤은 간만에 글을 작성해서인지 옛날로 돌아간것 같은 기분과 함께 왠지모를 뿌듯함을 느꼈다. 자신의 이런 기분을 누군가 알아주길 바라는 듯, 길가 벤치에 앉아 지나가는 사람들을 둘러보며 또다시 상념에 잠긴다.

  현재의 비트코인의 상징성과 파급력이 예전과 비교할때 상당히 몰락했다고 하지만, 어찌보면 언젠간 도래할 '영광의 하산'을 한거라고 그는 생각했다. 비트코인이 보여줄수 있는 가치와 가능성을 보여줄만큼 보여준 덕분에, 다른 프로젝트들이 시행착오를 덜 겪으며 더 빠른 속도로 빛을 발할수 있었고 그 모든게 큰 산업으로 발전하여, 킬러디앱(Killer Dapp)의 등장과 토큰의 대중적 수용(Mass adoption) 덕분에 전세게 경제금융에 새로운 패러다임을 제시했기 때문이다.
  여기서 중요한 것은 '왜 영광의 하산을 했냐'는 것이다. 그 이유는 하나에 있지 않고 여러가지 이유가 뒤섞여 특정 시점에 터졌다는 것이 그의 결론이다.
  우선, 분명 존재했지만 동시에 존재하지 않았던 사토시가 알고보니 잔인한 인물로 밝혀진 '사토시 스캔들'도 이유가 되었다. 혹자는 자살한 살인범 곁에 남겨진 사토시 지갑의 프라이빗키가 적힌 유서는 정부나 당국이 조작한 것이고, 진짜 범인은 분명 기득권층의 꼭두각시라는 음모론을 제기하기도 했다. 그게 사실이든 아니든 분명한 점은 대부분의 사람들의 머릿속에 사토시는 잔인한 존재로 각인되었다는 사실이다.
  또 다른 이유로는, '토큰의 양면성' 때문이다. 인터넷을 예를 들면, 인터넷은 과거에 즉각적 뉴스 제공하고 빅데이터를 탄생케한 혁신을 보여줬음에도 불구하고, 조용히 묻혔을 각종 사건, 사고가 인터넷을 통해 전세계에 빠르게 퍼지면서, 결국 세상은 폭력이 만연하므로 오직 힘으로 이 혼란을 잠재워야 한다는 정치적 선전도구로 전락해버렸다. 그런데 인터넷 이상으로 파급력 있고 활용성이 좋은 블록체인은 기존의 인터넷과 같이 거대한 분산 네트워크이자 즉각적인 디지털 커뮤니티를 구축하기도 했지만 토큰이라는 특수한 경제 메커니즘 역시 지녔다. 다만, 이 특성때문에 인간의 탐욕과 군중심리와 결합되어 전에 없던 새로운 전체주의(Neo Totalitarianism)가 촉발되었다. 이게 가능했던 이유는, 국제정서가 점점 더 혼란스러워지면서 늘어난 비트코인의 과격추종자들과 무정부주의자들이 서로 동질감을 느끼면서 그들만의 정신적 결속을 다졌고, 비트코인을 포함한 토큰들을 그들의 활동의 경제적 기반으로 삼았기 때문이다. 이렇게 국적을 초월한 전체주의 커뮤니티는 그림자 거버넌스의 교묘한 선동에 자극을 받아, 열혈 추종자 위주로 곳곳에서 유혈사태와 테러를 일으키면서 결국 그들 스스로 사토시 정신의 한계를 그어버렸다. 그러자 사토시는 역시 살인자 우두머리라는 사람들의 부정적 인식만 짙어졌다.
  그런데 영광의 하산의 결정적인 이유는 따로 있다. 바로 '거품'이 빠진것이다. 사토시가 끝내 자살한 연쇄살인범이라고 드러나면서, 비트코인은 한동안 사상 최고의 상승랠리를 기록한 뒤, ASIC채굴집단 등 암호화폐 기득권들간의 끝 모르는 정치적 다툼에 의해 네트워크 보안이 취약해졌고 그때쯤 그의 프라이빗키를 통해 획득한 '사토시 자산'인 100만개의 비트코인을 시장에 뿌려지면서 역대 최고 거품이 인류사에 기록되었다.

  죠셉은 주마등처럼 과거 자신이 취재해온 비트코인의 흥망성쇠를 생각하니 정신이 갑자기 혼란스러워졌고, 급 피곤해졌다. 한때 달러는 물론 금마저 대체할거라는 기대를 품게했던 비트코인의 역사가 왠지 자신의 인생역사와 오버래핑되는 것같아 묘한 동질감이 들었다.
  씁쓸한 마음을 안고 집 앞에 도착하여 현관문을 열때, 문 아래 틈으로 뭔가가 보였다. 서류봉투 하나가 문 아래 틈에 끼워져 있는 것을 보였고 고개를 서서히 숙이며 그 정체가 뭔지 파악하기 시작했다. 혹시 헨리가 뭘 놓고 갔나 아니면 구독하지도 않은 신문을 찔러놨나라는 생각을 하며 손을 뻗어 조심스럽게 봉투 모서리를 잡아당겼다. 그러자 문구 몇개가 눈에 띄였다. '최고급 기밀'이라는 글자와 함께 그 바로 아래에 네 글자가 적혀있었다.

  'L.U.C.Y'


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

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

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

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



□ 지난 회의 리뷰 및 추가 논의

  ㅇ EIP-1283(https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1283.md)
    - 지난 주말동안 Gitter를 통해 논의 한 결과, 기존 제안에 추가 섹션을 더했고 따라서 별도의 EIP이름으로 변경되어 다시 제안되어야 할 필요가 있다. 이미 지난 하드포크(Petersburg HF)이후 수 개월간 테스트넷에서 문제없이 실행되었기에 어느정도 검증도 되었다.
    - 다만, 세부 변경사항이 있는만큼 다른 EIP들과의 상호 보완/호환되는지와 그 자체로도 잘 실행되는지가 중요하다.
    - EIP-1706은 EIP-1283과는 완전 다른 별개의 제안으로 보는 의견에는, EIP-1706이 EIP-1283에 치료제같은 역할을 하며 따라서 상호연관이 있다는 반박이 있었다.
    - 기존 콘스탄티노플HF에 적용될뻔한 EIP로, 총 가스 계량기(Net gas metering)를 변경하여 컨트렉트 저장소를 위한 새로운 활용가능성과 대부분의 작동방식이 안 맞을때 발생하는 과도한 가스비 감소에 도움이 된다. 즉, 불필요한 가스비를 줄이는 코딩을 가능케한다.
    - EIP-1706와 관련되어있는 기존 콘스탄티토플HF 적용 후보EIP로, 그때에 비해 큰 변화는 없으며 관련 개발자가 추가되었다. 다만, 이스탄불HF에 적용시 이 두 EIP(1706, 1283)가 결합되어 적용될수도 있으나 아직 합의가 되지 않기 때문에 검토가 필요하지만, EIP-1283은 지난 HF에도 적용될수도 있었던 제안으로, 이미 준비가 되었기에 이스탄불HF적용되었으면 한다. 그전에 EIP-1283팀 간에 합의를 통해 최종 의견을 내세울테니 그때 최종승인할지 다뤘으면 한다.

  ㅇ EIP-2028(https://eips.ethereum.org/EIPS/eip-2028)
    - Calldata(이더리움 상에서 트랜잭션 요청시 전송 데이트가 저장되는 곳)의 가스비를 현행 바이트 당 68에서 줄인다. Calladata비용이 절감되면 잠재적으로 더 큰 블록이 생겨 네트워크 지연이 증가하지만, 수학적 모델링과 경험적 추정에 의해 네트워크 보안이 강해지고 확장성이 증가되는 부수적인 효과가 있을수도 있다.
    - Calldate 영역에서 가스비는 0byte일때 4Gas, 0byte가 아닐때는 68Gas가 소요되지만, 이 제안을 받아들이면 0byte가 아닐때 가스비가 줄어든다(단, 0btye일때는 여전히 4Gas 소요).
    -  이때 일종의 메모리 역할을 하는 Calldata 대역폭(수용능력)이 높아지면 한 블록당 더 많은 데이터를 넣을수 있기때문에 자연스럽게 확장성이 향상되나, Call데이터의 가스비가 줄어들면 1) 잠재적으로 블록크기를 크게 만들어 자연스럽게 데이터 전송에 따른 네트워크 지연을 야기하고 2) 네트워크 공격비용을 낮춰서 보안에 악영향을 끼친다.

 ㅇ EIP-2027(https://eips.ethereum.org/EIPS/eip-2027)
   - 인터넷 컨트렉트규모 계산(스테이트 렌트H)방식이다. 이더리움은 컨트렉트에 채워지거나 비워진 스토리지 슬롯갯수를 계산하는데, 기존의 슬롯갯수가 현재시점으로 계산하지 않기때문에 슬롯갯수의 순수 변화만 효율적으로 추적하는데, 이 개선으로 총 스토리지 슬롯갯수를 추적하게 된다.
    - 10월로 예정된 이스탄불HF일정에 맞게 이 제안의 개발을 추진가능하냐는 질문에, 해당 개발자는 현재 많은 일을 하고 있기때문에 HF일정에 맞추는 것은 결고 쉽지 않다고 말했다.


□ 로드맵(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)   *최종승인됨(63차 회의)
       - BLAKE2b라는 새로운 암호화 해싱 알고리듬을 구현하는 사전컴파일 컨트렉트를 EVM에 도입한다.


□ 개인 논평

  ㅇ 가까운 미래의 이더리움
    - 최근 이더리움2.0스펙이 확정(관련 정보는 여기 클릭)되었고 이미 이더리움 관계자가 비트코인 출시 11주년인 2020년 1월 3일에 이더리움2.0의 0단계를 개시할수도 있다는 언급도 있었다. 물론 필자의 사견으로, 2020년 초에는 0단계 개시가 결코 쉽지않을것이라고 보지만 지연(delay) 역시 개발의 과정이라고 생각하기에 조급해하지 않으려 한다(필자가 연초에 작성한 2019 이더리움 로드맵은 여기 클릭)
    - 이더리움2.0 스펙이 확정된 6월말과 이더리움2.0 0단계 개시사이에는 이스탄불HF와 데브콘5라는 빅 이벤트가 있다. 최근의 이더리움 개발자 회의에 주로 논의되는 내용이 바로 이 이스탄불HF에 적용시킬 EIP를 선정하는 작업이며 각 EIP담당자들은 본인의 프로젝트 작업외에도 이더리움 개선을 위해 오늘도 개발작업에 고군분투하고 있다. 이스탄불HF 바로 이전에 치뤄질 이번 데브콘5가 특히 기다려지는 이유는 바로 '예치금 계약식(Deposit Contract Ceremony)'가 예정되어있기 때문이다. 이는 1) 비콘체인이 출현할 0단계에 앞서서 안정적으로 예치금을 확보하고, 미리 예치금을 확보함으로써 2) 네트워크 안정성 및 이자율에 대한 파악을 미리 하여 여러 시뮬레이션을 할수 있고, 3) 잘못된 예치주소로 예치금을 전송하는 것을 방지하기 위해 정확한 특정주소로 전송하는 것을 안내할수 있다. 현재 이더리움 측에서는 2백만 이더가 예치되길 바라고 있으며, 예치금에 따른 이더 발행 금리표는 다음과 같다.
< 비탈릭이 정리한 PoS기반 이더 발행 금리표 (https://github.com/ethereum/eth2.0-specs/pull/971) >

    - 이스탄불HF가 지연없이 잘 완료되고 곧바로 데브콘5에서 예치금 계약식 등을 통해 이더리움2.0 분위기를 조성하면서 2020년에 이더리움2.0이 문제없이 출시되면 이더리움 네트워크와 커뮤니티가 새로운 도약을 함은 물론 투자자들에게도 기다림에 대한 충분한 보상이 있을거라고 여겨진다. 잠시 분석가 마인드를 내려놓고 투자자의 관점으로 볼때, 재작년의 이더리움 시세 폭등과 작년의 끝없는 이더 시세의 하락을 목격했던 바, 올해 말까지 시장은 이더리움을 어떻게 평가할지 사뭇 기대된다.


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

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

<1>
  "으으음,,,"

  죠셉은 괴로움에 신음하며 힘겹게 잠에서 깨어났다. 단순 숙취때문일까 아님 한때 잘 나갔던 시절이 떠오른걸까. 여튼 지금은 주체없이 술을 마신 어제의 자신이 야속하기만 할뿐이다. 침대에서 무거운 몸을 일으켜보니 숙취때문에 괴로운게 아니란걸 증명하는 듯 과거 자신의 특종 기사가 방바닥에 누워 그를 반겼다.

  「사토시 나카모토들의 연쇄살인범, '사토시 나카모토'」


  냉수를 벌컥 마시고나니 어젯밤 기억이 군데군데 찟긴 필름처럼 날듯말듯한다.

  "사토시 나카모토..."

  이미 꽤 지난 일이라 대중들에게 잊혀졌지만 돌이켜보니 죠셉은 차라리 그 스캔들이 없었더라면 하는 생각까지 들었다.

  2009년 초 비트코인을 출시한 사토시는 블록체인을 통해 새로운 화폐수단과 금융체제의 씨앗을 세상에 심고 도중에 사라진다. 그가 사라지면서 비트코인은 조용히 역사 속으로 사라지는가 했지만 그것의 가능성을 본 이들은 지속적으로 개발하고 응용하였다. 그리고 시간이 지나면서 점점 더 많은 사람들이 참여하게 되었고 비트코인은 더욱 더 그 가치가 높아졌다. 그 덕분에 비트코인은 어느 순간부터 기존의 주요 금융권도 무시하지 못하는 영향력을 뽐내기 시작했다.
  그런데 그 과정에서 자신이 '사토시 나카모토'라고 주장하며 유명세를 누리려는 사람들이 나타나기 시작하였다. 그들은 각자 나름대로의 주장에 근거하면서 사토시가 드디어 세상에 나타났다고 스스로 외쳤지만 시간이 지나면서 식상해질뿐 진짜 사토시의 출현에 갈증만 더해갔다. 그런데, 어느 순간부터 스스로 사토시라고 우기는 자들이 쥐도새도 모르게 살해를 당하는 일이 벌어졌다. 당시만 해도 열혈 청년이었던 죠셉은 블록체인과 암호화폐의 광팬인지라, 개인적으로도 직업적으로도 소위 '사토시 연쇄살인'에 대하여 상당한 흥미가 생겼고 기자로서도 뭔가 큰 일을 낼수 있을것만같은 강렬한 느낌을 받았다. 그런데 그 촉이 정말 현실이 되었다.

  '띵똥~ 띵똥~'

  "선배, 집에 계세요?"

  어제 술 상대가 되어준 후배 헨리가 초인종을 누르며 불러댔다.

  "선배, 안에 있어요? 혹시 나쁜 생각 한거 아니죠??

  '쾅, 쾅, 쾅'

  헨리는 답답한듯 문을 두드리기 시작했다.

  "문 부서진다. 나간다 나가"

  죠셉은 이런 일이 처음이 아니라는 듯 태연하게 문을 열어줬다.

  "아, 선배~ 전화도 안 받고 뭐하고 있있어요?"

  "뭐했을것 같냐"

  "응? 지금까지 잔 거에요? 난 또,,, 뭔일 생긴지 알았네"

  헨리는 자기가 좋아하는 선배가 종종 우울해하기도 했고 어제 술을 많이 마셔서 왠지 걱정되는 마음에 아침부터 달려왔다. 그런데 고마워하기는 커녕 귀찮아 하다니, 이젠 익숙해질만도 한데 이 선배에게 여전히 섭섭하다. 그런데 집안으로 들어가던 헨리는 방바닥에 나뒹구는 오래된 기사를 봤고, 갑자기 선배의 처지가 짠해졌다.

  "선배, 집에만 있으면 우울하니 바람도 쇨 겸 뭐 좀 먹을겸 밖에 나가게요"

  "..."

  "아, 어서요~"

  헨리가 집밖으로 끌어내려하자 죠셉은 못 이기는 척 현관문을 나섰다.

  여느 때와 같이 평범해 보이는 하루지만 세상은 하루가 다르게 변하고 있었다. 사회, 경제, 국제 등 다방면에서 있어 전세계는 새로운 파도에 출렁거리고 있었고 특히 경제금융분야에서의 혁명이 돋보였다.

  2009년 비트코인의 등장은 기존에 존재하던 달러, 유로, 엔 등의 신용/법정화폐의 위상에 상당한 영향을 끼쳤다. 주요 국가들의 정부와 중앙은행들, 심지어 대기업들까지 비트코인의 성장세를 지켜면서도 그것을 벤치마킹하여 새로운 금융시대에 주도권을 잡기 위한 전략을 모색하기 시작했다. 그들의 노력이 어느정도 성과가 보이자, 비트코인을 포함한 암호화폐의 성장이 그치고 이후 거품이 꺼지길만을 기다렸으며 실제로 거품이 빠지는데에 비밀리에 직접 개입하기도 했다.
  그게 정말 주효한걸까, 지속 우상향하리라던 많은 이들의 예상과 달리 어느 시점부터 암호화폐의 전체 시총과 시세가 빠지면서 주요 국가들은 그간 숨겨온 발톱을 드러내기 시작했고, 역대 최대의 거품이 꺼지기 시작한 비트코인은 여러 이유들이 엉키면서 서서히 '영광의 하산'을 하게된다. 그 과정에서 일명 '토큰패권주의'에 가장 먼저 치고들어온 국가는 다름아닌 바로 중국이었다.

  아침 겸 점심을 먹기로 한 죠셉과 헨리는 자주 가는 식당에 늘 지정석처럼 앉는 구석자리에 자리잡았다.

  "지금 생각해보면 중국이 참 영약했던것 같아요"

  헨리는 주문한 메뉴를 기다리면서 뭔가 생각난듯 내뱉었다.

  "뭐가...?"

  죠셉은 관심없다는 듯 창밖을 바라보며 답했다.

  "아니, 국가차원에서 암호화폐를 그렇게 단속하던 중국이 중앙은행을 전면에 내세워 국가토큰을 발행한 건 지금 봐도 놀라운것 같아요. 특히 흥미로운건 합의방식이름을 'One-BTF'라고 짓고 분기가 절대 발생하지 않게끔 섥했다는 점이에요. 그들의 이데올로기인 '하나의 중국'을 합의방식에까지 노골적으로 표현한것 같은데, 탈중앙화 블록체인에 중앙화 기치를 담으려는 그들이 참 무섭기도 하고 대단하기도 한것 같아요"

  "듣고 보니 그렇네"

  죠셉은 살짝 관심이 생기는 듯 주문한 식사를 맞이하며 시크하게 말했다.

  "또 하나 재미있는 건 토큰명이 'ONE'이라는 점과 그것의 발행량이 15억개라는 거에요. 비트코인이 역대 전고점을 향한 상승랠리가 이어질 때, 중국이 자국 인구에 맞게 발행량을 정한것 같은데, 이게 인민 한명당 토큰 1개꼴인거 보면서 중국 사회주의 특색이 묻어나오는 것 같기도 하고요"

  "그렇게 볼수도 있지. 아닌게 아니라 과거 덩샤오핑이 강조한 중국의 사회주의에는 공산당 주체하에 모두가 부유해지는 것이 포함되어있는데, 겉으로는 인민에게 1개꼴로 돌아갈수 있다는 것을 어필하면서도, 속으로는 수치적인 마케팅을 지렛대로 네트워크 주도권를 통제하면서 현실세계처럼 기득권들이 다 해먹겠다는 거 아니겠어. 중국이 과거부터 아닌척 하면서 블록체인 연구에 목멘것도 다 이유가 있었던 거지"

  죠셉은 이제야 정신이 들어 헨리의 말에 맞장구를 쳐줬다.

  "오~ 그럴듯한데요. 선배 아직 살아있는데요. 아무튼, 미국을 넘는 세계패권국가로 부상하려던 중국이 겉으로는 과거 무역분쟁때 미국에 치이고 내전에 흔들려 국가적 위기를 수습하면서도 뒤에서는 얼마나 이를 갈고있었을까 생각하면 소름이 돋는것 같아요"

  "그런의미에서 보면 미국 역시 미국다운 방식으로 토큰경제를 받아들였고 그걸 토큰경제민주주의로 승화했다고 볼수있지"

  "그러니깐요. DPos-BTF 합의방식으로 국가토큰을 발행하고, 각 주에 검증인을 두어 총 50개의 검증인이 생겼죠. 그렇게 설계하여 각 주마다 고유의 커뮤니티를 유지하면서도 각 검증인들 간 선의의 경제를 통해서 각각의 지역브랜드의 위치도 가늠할수 있고요. 대박인건, 미국 대선을 포함한 각종 선거때도 미국 특유의 선거인단 투표를 검증인체제에 그대로 반영하여 전자투표를 도입한 것도 신선했고요"

  "그게 다 처음에는 선거자금조달 편의성이라는 우연때문이지 않았을까. 자기 주머니에서 정치후원금 내는 것보다 암호화폐를 내는게 편하고, 더욱이 그 당시에는 코인시장이 지속 상승장이어서 토큰모금이 현금모금보다 더욱 수월한 점도 있었지. 그걸 제대로 간파한 눈치백단 정치인들이 타이밍을 잘 잡았고, 심지어 그렇게 선출된 대통령이 암호화폐에 우호적이던 의회와 맞장구치면서 아예 경제시스템을 토큰화시킨거고. 그뿐만 아니라, 거기에 달러를 찍어내던 미연준(FRB)도 기존의 권한을 유지한다는 조건하에 행정부와 의회랑 결탁했을거고. 결국엔 힘없는 서민들만 혁신이 만능인것처럼 좋아하다가 손가락만 빨게되는거 아니겠어"

  "흠,, 결론이 그렇게 나는건가요. 약간 다른 이야기지만, 그래도 서민들은 새로은 토큰경제가 태동한 덕분에 기본소득제(Basic income)가 도입되었다고 좋아하던데요. 또다른 4차산업혁명인 인공지능이 보편화되면서 우리의 일자리부터 위협당하기 시작했죠. 기존 산업혁명때처럼 새로운 기술로 인해 그만큼 새로운 일자리가 생길거라 예상했지만, 이번 산업혁명부터는 그 선례가 완전 빗나갔고 양질의 일자리는 커녕 전체 일자리가 줄어들어버렸죠. 그런 분위기에 기본소득제 도입에 대한 공감대가 형성되었고, 과거 기본소득제의 문제인 세수부족과 배분의 어려움을 주요 국가들의 정부와 당국이 블록체인기술과 암호화폐 발행으로 해소해버렸죠. 이래저래 새로운 세상이 열린것 같아요"

  "그러고보면, 그 덕분에 사람들이 기본소득에 충분히 만족하고 진정 원하는 활동을 하는 성숙한 사회가 존재할수 있었고, 다행스럽게도 국가차원에서 기본소득으로 쓰이는 토큰의 활용처가 빠른시일내 많이 구축되었지. 핵심은 정부와 당국이 기본소득토큰의 정책방향을  보유가 아닌 활용에 잡았다는 점인데, 현재까진 성공적인것 같아"

  "네 맞아요. 저번에도 같은 얘기한것같은데, 시의적절한 기술과 정책이었던 것 같아요"

  죠셉은 자신의 엄청난 통찰력과 식견에 놀라는 후배를 보며 으쓱하긴 커녕 오히려 불쾌하다는 듯 살짝 미간을 찌푸리며 식사를 마쳤다. 예전같았으면 그저 아무렇지 않게 들었을 말이겠지만 지금은 한물간 사람에게 칭찬은 사치라고 생각하기에 마냥 받아줄수 없었다.

  "사토시 스캔들,,,"

  죠셉은 한숨쉬듯이 작게 내뱉었다.


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

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

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