안녕하세요, 코인논객오공입니다.
지난 7.26(금)에 이더리움 개발자 회의(66차)가 있었으며, 그 내용과 분석과 개인 논평을 공유합니다.
*편의상 '~이다/하다'체로 작성하였음을 미리 양해바랍니다.
<제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)를 잘 견지할수 있을지 우리는 꾸준히 지켜봐야할것이다.
※ 출처 : https://www.satoshicode.com/2019/07/66-v10.html