이더 생태계의 이슈 프로젝트인 Monad와 MegaETH의 두 창립자는 최근 이더 의 향후 개발에 대해 열띤 토론을 벌였습니다. Monad 공동 창업자이자 CEO인 Keone Hon과 MegaETH 창업자이자 CTO인 Lei Yang은 이더 정렬, 전체 노드, 탈중앙화, 검열 저항 및 자체 검증의 중요성과 관련된 주제에 대해 논의했습니다. 풀노드에 대한 논의는 이더 창시자인 V God도 토론에 참여하도록 유도했습니다.
"풀 노드"에 대한 새로운 정의가 있습니까?
Keone과의 대화에서 Lei Yang은 "풀 노드"를 트랜잭션을 실행하지 않고 단일 순서 로부터 스트리밍 상태 델타를 수신하는 노드로 재정의하는 것처럼 보였습니다.
Lei는 일반적으로 거래를 확인하려는 MegaETH 사용자에게는 세 가지 옵션이 있다고 말했습니다.
1) 트랜잭션의 유효성을 검사하지 않고 대신 Keone이 언급한 종류의 순서 에서 상태 업데이트를 수신하는 노드를 실행합니다. 보안은 순서 의 사전 확인과 오작동 시 스테이킹 삭감된다는 보장에서 비롯됩니다. 이는 중소규모 거래 및 실시간 최종성이 필요한 상황에 적합합니다.
2) 1과 동일하지만 사용자는 낙관적 증명의 챌린지 창이 만료되고 트랜잭션이 포함된 MegaETH 블록이 이더 에서 완료될 때까지 기다립니다. 이것이 "완전한 이더 보안"입니다. 역방향 트랜잭션은 마치 이더 트랜잭션이 역방향인 것처럼 동일한 슬래싱을 트리거합니다. 이는 사용자가 현지 확인을 원하지 않지만 높은 가치의 거래를 기대하는 경우에 좋습니다. 이 사용 사례는 드뭅니다.
3) 각 거래를 검증하고 거래가 포함된 MegaETH 블록이 이더 에서 완료될 때까지 기다리는 전체 노드를 실행합니다. 이것은 또한 "완전히 이더 보안"입니다. 이는 사용자가 정기적으로 고부가가치 거래를 기대하고 거래를 신속하게 완료하기를 원할 때 유용합니다. 예를 들어, 거래소.
MegaETH 사용자는 기본적으로 위의 세 가지 옵션 중 하나를 선택할 수 있으므로 대기 시간, 노드 하드웨어 요구 사항 및 거래 확인 보장 간에 절충점이 있습니다.
MegaETH가 모든 거래를 검증하는 노드를 가질 수 없다는 점에서 혼란이 있는 것 같습니다(위의 옵션 3). 이것은 잘못된 것입니다. 이 세 가지 유형의 사용자가 공존합니다. 노드가 모든 트랜잭션을 검증하기로 결정하더라도 강력한 순서 보다 더 효율적으로 검증(재실행)하기 위해 많은 트릭을 적용할 수 있다는 점에 유의하는 것이 중요합니다. 따라서 하드웨어 요구 사항은 여전히 순서 보다 훨씬 낮습니다. 예를 들어, 트랜잭션을 검증할 때 상태 데이터베이스(주요 병목 현상)를 읽을 필요가 없습니다. 왜냐하면 순서 증인(블록을 검증하는 데 필요한 상태와 해당 트라이 증명)을 제공할 수 있기 때문입니다. L1의 경우는 그렇지 않습니다.
불행하게도 Keone과의 논의는 L2 풀 노드가 무엇인지(주제에서 벗어남)에 초점을 맞추면서 다음 사실을 무시한 것처럼 보였습니다. (1) 절충안이 존재합니다. (2) 절충안이 사용자에게 제공되어야 합니다. (3) 이더 L2는 이를 수행하는 데 매우 적합합니다.
Keone은 "그건 좋은 말이지만, "옵션 1" 노드(당시에는 풀 노드라고 불렀음)의 이점을 홍보하던 어제와는 전혀 다른 것 같다고 답했습니다. 녹음이 있으니 가서 들어보세요! 이제 자체 검증 노드에 더 중점을 두시는 것 같은데, 이는 제가 동의하는 방향입니다.
Lei는 낙관적 풀 노드(모든 트랜잭션을 다시 실행하지 않음)를 갖는 것의 이점/중요성을 내가 원하는 만큼 반복해서 기뻐할 것이라고 말했습니다. 이러한 노드는 확인 보장과 운영 비용 간에 의미 있는 균형을 제공하므로 대부분의 사용자가 관심을 갖는 유형입니다. 이번 에피소드에서 제가 언급했듯이, 그들이 받는 보장은 암호경제학입니다. 사용자가 속이는 경우(거래가 역전되는 경우) 시퀀서가 슬래시됩니다. Vitalik이 설명하는 https://x.com/VitalikButerin/status/1826497936676860184 또한 사용자에게 보상을 제공하고 보안 모델을 더욱 강화할 수 있습니다. 이러한 노드는 중소 규모 트랜잭션을 자주 처리하는 사용자와 실시간 성능이 필요한 사용자에게 적합합니다. 이러한 유형의 애플리케이션은 MegaETH에서 고유합니다. 다시 한번 강조하자면, 대부분의 MegaETH 사용자는 자체 검증이 필요하지 않습니다.
나는 (1) MegaETH가 순서 보다 훨씬 가벼운 하드웨어를 사용하여 자체 검증 전체 노드를 지원한다는 점을 명확히 하고 (2) 확인 보장, 시간 및 노드 하드웨어 간의 균형이 범위에 있음을 지적하기 위해 다른 유형의 전체 노드를 언급합니다. , 자체 검증 전체 노드만으로는 동시에 달성할 수 없습니다.
뷔 신이 대답하자, L2의 '풀노드'에 너무 집중하는 것은 요점을 놓치는 것 아닌가? 사용자의 관점에서 볼 때 중요한 질문은 다음과 같습니다. 거래가 승인될 것이라고 얼마나 보장합니까?
두 가지 수준이 있습니다.
1) 바인딩 순서 사전 확인:
귀하의 거래가 승인되거나 순서>= N ETH 또는 기타 토큰을 잃습니다.
이는 Stakesure 개념을 통해 더욱 확장될 수 있습니다.
귀하의 거래가 승인되거나 순서 로부터 사전 합의된 금액으로 보상을 받습니다.
2) L1 확인:
귀하의 거래가 승인되거나 L1이 취소됩니다 (L1이 복구되더라도 인센티브로 인해 순서 정직하게 될 수 있습니다. L1이 확정되면 L1 취소가 불가능해집니다)
L1과 L2는 본질적으로 다릅니다. L1은 탈중앙화 의존할 다른 것이 없기 때문에 훨씬 더 어렵습니다. L2 사용자는 L2의 증명 시스템에 의존할 수 있으므로 스스로 이를 수행할 필요가 없습니다(우리 생태계가 점점 더 유효성 증명을 향해 이동함에 따라 이는 더욱 사실이 될 것입니다). 
Keone은 Buterin에게 다음과 같이 대답했습니다. 하지만 거래소 특정 Optimistic L2로부터 입금을 수락하면 사기 방지 기간 때문에 7일을 기다리는 대신 자체적으로 입금을 하고 싶을 것입니다. 그렇죠? 
비탈릭 부테린 (Vitalik Buterin) 개인 사용자(거래소 포함)가 자신의 선호도에 따라 사기 방지 창구를 설정할 수 있다고 말했습니다. Stakesure 기술을 사용하면 이 작업을 수행할 필요조차 없습니다. 즉시 입금이 성공했는지 확인하거나 보상을 받을 수 있습니다(즉, 무슨 일이 있어도 동일한 금액을 얻습니다). 장기적으로 우리 모두는 사기 방지 기간을 덜 문제로 만드는 ZK를 채택할 것이라고 생각합니다. 
물론 거래소 사기 방지 창구를 다르게 설정할 수 있다고 Kenoe는 믿습니다. 그러나 자동 집행을 피할 수 있는 합리적인 중간 지점이 있습니까? 예를 들어 대규모 예치의 경우 검증인 노드가 재생해야 하는 트랜잭션 수를 고려하면 6시간은 상당히 공격적으로 보이지만 사용자 경험 역시 다른 대안에 비해 상당히 열악한 것으로 보입니다. 또는 6시간 대신 1시간을 사용해도 여전히 작동하지 않습니다.
ZK는 확실히 장기적인 미래를 가지고 있지만 Megaeth는 처리량 제한으로 인해 첫날에는 ZK를 사용하지 않을 것이라고 말합니다. 나는 현재 결제를 허용하는 실제 비즈니스의 경우 "풀 노드 실행", 즉 모든 거래를 실행하는 것이 매우 중요하다고 항상 믿어 왔습니다. 나는 이것이 중요한 관점 라고 생각한다. 
