이것은 너무 과도합니다. 최근 며칠 동안 Devcon에서 많은 행사에 참석했는데, 이더리움(ETH)이 3.0 버전인 BeamChain으로 업그레이드되고 layer2 약물이 나온다는 소식을 들었습니다(화가 나네요). 이미 수동적인 상황에 놓여있던 layer2가 또 다시 배신당하면서 급락했습니다. 사실 이는 큰 호재입니다! 제 의견을 말씀드리겠습니다:
1) 새로운 체인이 나온다고 해서 대규모 포크(Fork)나 새로운 코인 발행이 있을 것이라고 생각하지 마세요.
Justin Drake가 말했듯이, BeamChain은 단지 BeaconChain(신호 체인)에 대한 업그레이드일 뿐이며, 현재 제안 단계에 불과하고 공식 출시까지는 아직 시간이 많이 남았습니다. 또한 이더리움의 로드맵을 완전히 따르고 있습니다.
이더리움은 BeaconChain(신호 체인)과 이더리움 가상 머신(EVM) 실행 체인으로 구성되어 있습니다. 신호 체인은 합의 계층의 역할을, EVM은 실행 계층의 역할을 합니다. 체인이라는 이름이 붙었다고 해서 완전히 새로운 것이 나오는 것은 아닙니다. BeamChain은 단순히 BeaconChain에 대한 과도기적 업그레이드일 뿐이며, 이더리움 체인의 실행에는 전혀 영향을 미치지 않습니다.
어디서 이더리움 3.0이 나왔죠?
2) BeaconChain이 왜 업그레이드되어야 하는지 설명드리겠습니다:
이더리움 EVM 실행 계층에서 블록 제안자(Proposer), 중계 노드(Realy), 검증자(Validators)는 각각 "프로젝트 관리자", "근로자", "품질 검사원"의 역할을 합니다. 사용자가 트랜잭션을 Mempool에 제출하면, 블록 생성자(Builder)가 트랜잭션 풀에서 트랜잭션을 선택하여 패킹합니다. 이 과정에서 트랜잭션 정렬 기능이 처리되며, 구축된 블록은 중계 노드를 통해 배포됩니다. 그리고 제안자가 최적의 블록을 선택하면 검증자가 최종 검증합니다.
이 과정에서 Builder의 트랜잭션 정렬과 Realy의 트랜잭션 배포 부분에 과도한 중앙화 요소가 존재합니다. 예를 들어 Flashbot과 같은 대형 빌더가 블록 순서를 결정할 수 있어 MEV(Miner Extractable Value)가 발생할 수 있습니다. 이는 이더리움의 큰 전략과 부합하지 않습니다.
따라서 Justin은 Builder의 블록 구축 과정에 inclusion list라는 필수 포함 트랜잭션 목록을 추가하는 아이디어를 제안했습니다. 이를 통해 Builder와 중계 노드 등의 중앙화 개입이 발생하면, 제안자가 블록 구축을 감독하고 이후 합의에 참여하는 제안자-빌더 분리(PBS) 방식으로 해결할 수 있습니다. 검증자가 핵심 트랜잭션이 목록에 없는 것을 발견하면 해당 블록을 즉시 무효화할 수 있습니다. 이를 통해 블록 생성 과정의 탈중앙화 속성을 높여 검열 저항성을 강화할 수 있습니다.
그렇다면 이 inclusion list를 실행 검증 과정에 어떻게 추가할 것인가? 이는 BeaconChain 합의 계층에서 처리해야 합니다. 하지만 현재 BeaconChain은 이 기능을 지원하지 않기 때문에 BeamChain으로 업그레이드해야 합니다. 이후 신호 체인은 모든 필수 포함 트랜잭션을 공개할 수 있으며, 실행 계층에 문제가 발생하면 검증 노드가 이를 거부할 수 있습니다.
또한 Pectal 업그레이드를 통해 스테이킹 요구 조건이 32이더(ETH)-1이더(ETH)로 변경되는 문제가 있어, BeaconChain의 경제 모델과 관리 논리 변경이 필요하므로 대규모 버전 업그레이드가 필요합니다.
더욱이 이더리움이 향후 Verge 단계에서 전면적으로 SNARKs화되면, 신호 체인과 이더리움 가상 머신(EVM) 실행 체인의 검증 과정에서 SNARKs 최적화가 필요하며, 양자 내성 암호화도 이더리움의 전략적 목표 중 하나이므로 BeaconChain 업그레이드가 필요합니다.
따라서 BeamChain의 등장은 이더리움 로드맵에 따른 일련의 필수적인 준비 작업입니다.
3) 왜 layer2에 대해 악재가 아니라 큰 호재라고 말씀드리는지 설명드리겠습니다.
첫째, 이더리움은 이미 Rollup 중심의 확장 전략을 수립했습니다. BeamChain 업그레이드가 이 근본 전략을 흔들 리는 없습니다. 그렇지 않다면 Justin의 제안이 이더리움 커뮤니티의 승인을 받기 어려울 것입니다.
둘째, BeamChain의 새로운 신호 체인이 이더리움 메인넷 수준의 확장을 가능하게 할 것이라고 말씀드렸는데, 핵심은 SNARKs화입니다. SNARKs 적용 후에는 이더리움 전체 프레임워크가 모든 데이터를 저장하고 계산하는 것에서 증명만 검증하는 것으로 바뀌어, 큰 확장이 가능해집니다. 하지만 이는 기저 데이터 구조의 논리적 ZK화 결과이며, layer2의 확장과는 다른 차원의 일입니다. layer2는 운영 비용 절감, layer2는 트래픽과 사용자 시나리오 확장을 담당합니다. 따라서 메인넷 확장이 이루어졌다고 해서 layer2가 약화되는 것은 아닙니다.
셋째, 최근 제가 발표한 글에서 Vitalik Buterin이 이더리움 전면 SNARKs화와 이더리움 가상 머신(EVM)이 altVM 중 하나로 메인넷에 존재할 것이라는 구상을 설명했습니다. 이 경우 다른 뛰어난 layer2 altVM이 메인넷 수준에서 이더리움 전체 생태계의 트랜잭션을 병렬로 실행할 수 있게 될 것입니다.
이런 맥락에서 BeamChain의 역할도 더욱 중요해질 것이며, 이 업그레이드가 매우 필요합니다. 또한 이더리움 확장 요구를 충족하는 우수한 VM 솔루션들이 메인넷 레벨에 흡수되어 실행될 것이므로, layer2 간 상호운용성도 원활히 해결될 것입니다. 이는 layer2 발전 전략과 완전히 부합합니다.
현재 특징 없이 범용적인 layer2가 많은데, 이더리움이 모듈화 접근법과 alt-VM 신전략을 채택한다면 많은 layer2가 이더리움의 직접적인 "상승 통로"를 얻게 될 것입니다. 이는 layer2 간 재편과 최적화를 촉진할 것이므로, 이는 분명 호재가 될 것입니다.
마지막으로, ZK 시대의 도래를 기대해 주시기 바랍니다. 이런 식으로 논리 없이 FUD를 퍼뜨리거나 루머를 만들지 마세요. (링크를 보시면 ZK 분야 프로젝트들이 무엇을 하고 있는지 배울 수 있습니다.)
