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

  죠셉은 충분히 안전하다고 생각이 될 정도로 멀리 와서야 조금 정신을 차렸고 거기서 발견한 모텔에서 며칠간 지내면서 생각을 정리하기로 했다. 일단 자기 집에서 벌어진 사건에 대하여 만 하루가 지나도 온오프라인상으로 단 하나의 기사도 없었고 자기가 아는 기자들을 통해서도 그와 유사한 사건사고 내용을 들을수 없었다. 인정하고 싶지 않았지만 자기 대신에 애먼 후배가 당했고 이 사건이 난 이유는 바로 기밀서류라는데 자체결론을 내렸다. 문득 위험해지더라도 파볼거냐고 물어본 데이빗의 질문이 떠올랐다. 이렇게 될줄 누가 알았겠는다. 만약 스스로 낸 결론이 사실이라면, 이렇게 된 이상 후배의 죽음이 헛되지 않도록 끝까지 가보기로 했다.

  며칠간 고민을 한 끝에, 데이빗을 다시 찾아가 보기로 했다. 대신에 데이빗이 믿을만한 사람이라해도 기밀서류에 대해 알고있는 존재였기에 기밀서류 원본은 안전한 장소에 놓고 적당히 주요내용을 적은 사본을 갖고 방문하기로 했다. 총까지 챙겨 다시 찾아간 데이빗의 집에 마침 그가 있었고 기다렸다는듯이 그는 죠셉을 지난번처럼 반겼다.

"마침 잘왔네. 저번에 자네가 준 자료에 대한 분석이 끝났네."

"..."

죠셉은 말없이 무표정으로 고개만 살짝 끄덕였다.

"자네때문에 나까지 위험해질수 있지만, 나 역시 자네와 같은 배를 타기로 했네"

"네, 선생님 이해해주셔서 고맙습니다."

"혹시 원본은 갖고 왔나"

"네 여기 있습니다"

데이빗은 원본을 자세히 확인한 후 죠셉을 응시하며 말했다.

"나도 이 내용은 백프로 이해하지 못하기 때문에 여기저기 자문을 구했네. 원본내용을 딱 보니 역시 예상대로 시간을 끌면 안될것 같군. 그래서 도움을 받을 전문가분들을 바로 부를까 하는데 괜찮겠나?"

  죠셉은 이 불안한 시기에 잘 모르는 사람들을 만나는게 불쾌했지만 어쩔수 없었다. 이젠 못 먹어도 고다. 전문가들을 기다리는 동안 데이빗은 죠셉에게 요약서에 대해서 알아낸 정보들을 설명하였고, 죠셉은 며칠간 마음고생한 것은 잠시 잊고 기밀서류에 집중하기 시작했다. 

  그리고 잠시 쉬는시간에 죠셉은 화장실에 들러 다시 데이빗의 서재로 돌아가는데 낯익은 쟈켓이 보였다. 그 자켓은 평범한 디자인이 아니어서 기억나는데 어디서 봤는지 생각이 날듯말듯 하였다. 계속 생각하면서 서재에 들어서자 데이빗은 상기된 표정으로 죠셉을 보며 말했다.

"전문가들이 거의 도착했다니 배웅 좀 나가야겠네.  자네는 집에 좀 있게."

  바로 그 순간 죠셉은 그 자켓을 어디서 봤는지 생각났다. 바로 후배가 자기 집에서 당한 날, 창문을 통해 집 안에서 발견한 누군가가 입고있었던 자켓이었다. 아차 싶은 순간에 데이빗이 집을 나서는 동안 기밀서류를 챙겨 나가려고 했지만 서류는 눈에 띄지 않았다. 그냥 집을 빨리 나서야겠다고 결심한 순간 현관에서 데이빗과 마주쳤다.

"자네 지금 어디 가나"

"...."

말없이 품안에 총을 꺼내려는 제스쳐를 하는 데이빗을 보자 이제는 알았다는듯 심호흡을 하고 오히려 되물었다.

"지금 무슨 일이 벌어지고 있는거죠?"

"뭘 말인가"

"왜 이렇게 변하셨나요?"

데이빗은 자기 몸뒤로 현관문을 걸어잠구면서 대답했다.

"자네가 갖고온 자료는 내가 자문으로 참여한 프로젝트에 대한 내용이네. 이건 절대 누출되서는 안되는 기밀인데, 운좋게 자네가 날 찾아왔고 나까지 위험해지지 않으려면 어쩔수 없었네"

"하아,, 그래서 꼭 이렇게 했나요?"

"이렇게 하지 않으면 내가 위험해지니깐. 그치만 자네를 꼭 죽음으로 몰고 싶지는 않아. 그래서 한가지 부탁을 하자면 곧 전문가들이 도착할때까지 아무 말썽 피우지 않았으면 하네."

"아, 그 전문가들이 그쪽으로 전문가들이군요."

죠셉은 두려움보다는 배신감과 허탈감에 헛웃음만 나왔다.

"선생님, 하나만 묻죠. 저로 인해 선생님이 살아남아도, 끝까지 죽음의 위협에서 자유로워질거라고 생각하나요?"

"자네 말대로 나중에 나도 단물 다 빠지면 제거될수도 있지. 하지만 자네생각보다 난 꽤 쓸모있는 사람이고 나도 나만의 계획이 있어"

"선생님의 그 자신감이 참 부럽네요. 이런 분인줄 알았으면 혼자 우울해하기 보다 선생님 뵈면서 저도 자존감 올릴걸 그랬나봐요"

  그때 2명의 '전문가'들도 집 앞에 도착했다. 죠셉은 이제 정말 끝이라는 생각이 들면서, 곧 후배를 만나서 미안하다는 말을 전해야겠다는 생각만 들었다. 그때 총성이 울렸다.

'탕, 탕'

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

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


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