의견: "상태" 관점에서 이더리움과 그 미래 이해

편집자 주: 이 기사의 출처는이더리움 애호가(ID: ethfans), 승인을 받아 Odaily에서 재인쇄했습니다.

편집자 주: 이 기사의 출처는

이더리움 애호가(ID: ethfans)이더리움 애호가(ID: ethfans), 승인을 받아 Odaily에서 재인쇄했습니다.

첫 번째 레벨 제목

I. 소개

2015년에 생성된 이후 이더리움 블록체인은 5번의 겨울과 여름을 거쳤습니다. 5년은 개념으로서의 이더리움 프로토콜 1을 현실로 전환했을 뿐만 아니라 이 프로토콜을 더욱 성숙하고 구체적으로 만들었을 뿐만 아니라 이러한 일련의 설계의 특성과 장단점을 드러냈습니다. 이러한 트레이드 오프는 설계 과제로서 자연스럽게 이더리움의 사용성을 개선하기 위해 수많은 인재를 유치하고 지속적으로 유치하고 있으며, 그 중 가장 많은 노력과 상상력을 모으는 것은 "확장성" 일련의 계획을 개선하는 것입니다.이 기사에서 지적하고 싶은 것은 이더리움 패러다임이 디자인 트레이드 오프에 직면한 것처럼 이러한 모든 확장성 솔루션도 트레이드 오프에 직면한다는 것입니다. Ethereum 노드와 Ethereum 사용자의 실제 문제와 실제 요구 사항. 이더리움 자체를 이해하기 위한 관점인 "상태" 관점은 이러한 계획의 설계를 명확히 하고 우리의 이득과 손실을 드러내는 데 도움이 될 수 있습니다.이 기사는 "상태"의 의미를 설명하는 것으로 시작하여 이더리움의 궁극의 창과 아킬레스 건을 밝힌 다음 개선을 위한 다양한 방향을 모색할 것입니다. "풍부한 상태"는 이더리움 스마트 계약에서 "구성 가능성"의 원천이지만 이더리움 네트워크의 가장 큰 약점이기도 합니다. 이를 통해 우리는 자주 언급되는 솔루션이 "결합성"에 영향을 미치고 어떤 "확장성"이 더 분명한 의미를 갖는지 알 수 있습니다.2. 패러다임으로서의 이더리움(1) 풍부한 상태 및 구성 가능성"상태"란 무엇입니까? 상태는 특정 순간에 시스템의 특정 상황입니다. 암호화폐를 구현한 블록체인을 예로 들면, 특정 순간 블록체인의 상태는 그 순간 블록체인에 있는 모든 주소의 자산 분포입니다(주소 A는 10코인, 주소 B는 100코인 등). 사실, 우리가 가진 것은 우리의 마음과 사회적 합의에 의해 "자산"으로 해석되는 일부 상태일 뿐입니다.이러한 관점에서 각 블록체인 프로토콜 세트는 대략 두 부분으로 나눌 수 있는데, 하나는 합의 메커니즘이고 다른 하나는 상태 전환 규칙(때때로 "합의 규칙"이라고도 함)입니다. 블록체인에 참여하는 모든 노드가 블록체인 데이터베이스의 상태를 로컬에서 업데이트해야 할 때(예: Ethereum 블록체인의 노드로서 난이도 요구 사항을 충족하는 작업을 수신할 때마다 노드는 로컬 블록체인의 최신 상태를 업데이트합니다. 상태 전환 규칙은 어떤 트랜잭션이 유효한지 정의하고("계정은 자신의 잔액보다 더 많은 돈을 쓸 수 없습니다") 트랜잭션을 처리할 때 노드가 상태를 업데이트하는 방법을 정의합니다("이 트랜잭션은 해당 계정을 의미합니다. A가 B계좌로 5코인을 이체하면 A계좌의 잔고는 5가 줄어들고 B계좌의 잔고는 5가 더해집니다.Bitcoin의 경우 합의 메커니즘은 "PoW + Nakamoto Consensus"이며 상태 전환 규칙은 UTXO를 기반으로 합니다. Ethereum의 경우 블록 생성 메커니즘은 "PoW + Ghost 규칙"이며 상태 전환 규칙은 계정을 기반으로 합니다.그렇다면 이더리움을 획기적인 혁신으로 만드는 것은 무엇입니까?우리는 이더리움이 특별한 이유가 "프로그래밍 가능성을 지원하는 튜링 완전 프로그래밍 언어를 도입"했기 때문이라는 말을 자주 듣습니다. 사실 이 진술은 정확하지 않다 2. 더 복잡한 프로그래밍 언어를 허용하는 것은 아무 의미가 없기 때문에 사실 비트코인도 프로그래밍할 수 있습니다. 이더리움을 정말 특별하게 만드는 것은 "풍부한 상태 저장"3입니다. 이더리움은 하나의 컨트랙트가 다른 컨트랙트를 호출할 수 있도록 하며, 블록 크기 자체와는 별개로 이러한 호출 수준의 수에 제한을 두지 않습니다.컨트랙트 B는 컨트랙트 A가 공개한 코드에 따라 컨트랙트 A를 호출하여 컨트랙트 A의 상태를 변경할 수 있고 컨트랙트 B를 호출하는 컨트랙트 C도 간접적으로 컨트랙트 A를 호출하여 컨트랙트의 상태를 변경할 수 있지만 제어 로직이 너무 겹칠 수 있습니다. 상태를 자산으로 이해한다면 이는 자산의 사용권(사용조건)을 보다 엄격하고 복잡하게 지속적으로 통제할 수 있도록 하는 것과 같으며, 이는 이론적으로 상태 업데이트 로직을 의미합니다. 실생활의 금융 계약에 무한히 근접할 수 있습니다(모든 금융 계약은 간단한 논리를 통해 중첩되고 결합될 수 있기 때문입니다). 임의의 제어 계층을 축적할 수 있는 이 특성이 가장 중요하지만 이 제어를 프로그래밍하는 방법은 부차적입니다.또한 이더리움은 사용자가 블록체인에 상태를 기록할 수 있도록 하여 이러한 상태를 글로벌 상태의 일부로 만들고 계약에서 정의한 논리에 따라 노드가 상태를 업데이트하도록 요구합니다. 결과적으로 계약은 이더리움의 다른 모든 계정에 자체 상태를 공개할 수 있으며 앞서 언급한 풍부한 상태 저장이 실제로 작용합니다.맞습니다. 이제 드래곤볼 수집과 같은 세 가지 속성을 수집했습니다.

(1) 체인의 컴퓨팅 패러다임: 계약은 노드가 정의된 논리에 따라 계산을 수행하도록 요구할 수 있습니다.

(2) 글로벌 상태: 계약 상태는 글로벌 상태의 일부가 될 수 있으며 다른 모든 계정에 공개될 수 있습니다.(3) 풍부한 상태: 계약은 서로 호출할 수 있으며 스택 레이어 수에 제한이 없으므로 제어 논리가 레이어별로 누적될 수 있습니다.이제 우리는 Ethereum의 가장 강력한 창인 "Composability"(화폐 LEGO)를 부를 수 있습니다!체인의 컴퓨팅 방법을 사용하면 다양한 계약을 체결할 수 있고, 글로벌 상태에서는 이러한 계약이 서로의 상태에 액세스할 수 있으며, 풍부한 상태에서는 계약 조합이 무한히 다양해질 수 있습니다. 그래서 우리는 안정적인 통화 DAI를 가질 수 있을 뿐만 아니라 대출 시장, 복권 응용 프로그램, 복권 수익금을 자동으로 기부하는 응용 프로그램, 서로 다른 대출 시장 간의 저축 비율을 자동으로 재조정하는 응용 프로그램을 가질 수 있습니다... …(2) 상태 데이터 폭발 문제"합성 가능성"은 사실이 되기에는 너무 좋습니다. 그렇죠? 예, 위 세 가지 속성의 삼위일체는 실제로 양날의 검입니다.Ethereum의 상태 전환 프로세스는 다음과 같이 추상화할 수 있습니다. 상태 전환 기능은 이전 상태 및 트랜잭션 목록을 입력으로 사용하고 새 상태를 출력합니다. 즉, 이더리움의 전체 검증 노드는 로컬에서 이더리움 블록체인의 최신 상태를 유지해야 상태 기능을 실행하고 그 결과를 사용하여 블록의 유효성을 검증할 수 있습니다(또한 다른 이더리움 노드와 합의).모순은 계약과 개발자에게 계약 상태는 이더리움의 글로벌 상태의 일부로 이더리움 노드에 저장되고 계약의 상태 업데이트는 이더리움 노드에 의해 계산된다는 것입니다. 그리고 또한 계산 요청을 시작하는 노드에 의해 사용자가 지불합니다), 이 "서버리스" 아키텍처는 매우 편안합니다. 업데이트는 결제가 필요하지만 피할 수 없으며 상태 데이터는 계속 누적되고 확장됩니다.

상태 데이터의 확장이 문제인 이유는 전체 검증 노드에 점점 더 높은 하드 디스크(랜덤) 읽기 및 쓰기 부담을 가져올 것이기 때문입니다. 상태 데이터는 블록 데이터와 다릅니다.블록 데이터는 정적이며 영구 저장 후 자주 읽고 쓸 필요가 없지만 상태 데이터는 추가 블록마다 여러 번 읽고 써야 합니다. , 읽기 및 쓰기의 부담 점점 무거워집니다. 지난 몇 년 동안 우리는 사람들이 이더리움의 전체 노드를 배포하기 어렵다고 말하는 것을 자주 들었는데 이것이 주된 이유 중 하나입니다. 얼마 전 Infura의 무료 이더리움 노드 서비스가 4개 충돌하여 Infura에 의존하는 많은 서비스가 충돌했습니다.

이 문제는 해결하기 쉽지 않습니다. 지난 몇 년 동안 Ethereum의 여러 하드 포크 업그레이드는 상태에 액세스하는 opcode의 가스 소비를 증가시켰으며, 이는 경제적 비용으로 계약에 의한 새로운 상태 생성을 정확하게 억제하기 위한 것입니다. 그러나 이것은 명백히 임시 방편일 뿐입니다. 논리가 근본적으로 변경되지 않았기 때문에 상태 데이터는 이더리움 노드에 계속 저장되어야 하지만 상태 데이터를 생성하는 사용자는 한 번만 지불하면 됩니다. 또한 이를 변경하려면 국가가 임대료를 지속적으로 지불하도록 하는 계약을 요구하는 일종의 "국가 임대료" 메커니즘을 도입해야 하며, 그렇지 않으면 계약의 가용성이 종료될 것이라고 제안되었습니다. 그러나 이 메커니즘은 상상할 수 없는 복잡성을 가지고 있으며, 한편으로는 합리적인 임대료 징수 방법을 결정하기 어렵고, 다른 한편으로는 합리적인 지불 대상을 결정하기도 어렵습니다. 그래서 국가 임대료 메커니즘에 대한 연구도 20195년에 정체되었습니다. 보유하고 있는 통화의 양에 따라 사용 가능한 상태 공간의 크기를 정의하려는 프로젝트(예: Nervos)도 있으므로 상태 데이터의 크기에는 항상 상한이 있으므로 상태 확장 문제를 피할 수 있습니다. 그러나 이것은 또한 원래 자산, 경제적 속성을 변경합니다.

지금까지 저는 이 문제에 대해 현실적으로 많은 도전에 직면한 "무국적" 외에 만족스러운 근본적인 해결책을 보지 못했습니다. 이에 대해서는 나중에 이야기하겠습니다.

대체로 글로벌 상태, 온체인 컴퓨팅 및 풍부한 상태는 이더리움의 계약을 구성 가능하게 만들 뿐만 아니라 이더리움 네트워크를 중앙 집중화의 위험에 빠뜨립니다. Rings" 는 강력한 힘을 소환할 수 있을 뿐만 아니라 사용자 자신을 집어삼킬 수도 있습니다. 이더리움이 이 부담을 오랫동안 짊어질까 봐 걱정됩니다.
다음으로 "상태" 관점을 사용하여 다양한 확장성 솔루션의 설계 및 장단점을 이해합니다.3. 이더리움의 발전 방향이 장에서는 이더리움의 네 가지 개발 방향인 레이어 2 체계, 샤딩, 상태 비저장 및 롤업 체계를 분석합니다. 이러한 분류는 롤업이 Layer-2 체계의 하위 집합이고 상태 비저장은 사전 샤딩 기술이기 때문에 완전히 불합리합니다. 샤딩 및 무국적에는 이러한 요구 사항이 있습니다. 이것은 설명과 이해의 편의를 위해서만 수행됩니다.(1) Layer-2 방식Layer-2 방식의 아이디어는 간단하지만 매우 정확한 직관에서 나옵니다. Ethereum이 처리량 병목 현상에 직면하는 이유는 Ethereum 네트워크를 구성하는 노드의 대역폭, 컴퓨팅 성능 및 상태 데이터를 유지하는 기능이 모두 제한적이며 개선이 어려우며 전체 네트워크의 노드가 단위 시간당 더 많은 트랜잭션을 처리하도록 요구하면 노드의 운영 요구 사항이 필연적으로 증가하여 탈중앙화를 손상시키지만 사용의 관점에서 볼 때 모든 상태를 이더리움에 둘 필요가 없고, 모든 상태 계산이 이더리움에서 일어나게 할 필요는 없으며, 계약의 중간 상태(또는 모든 상태)를 다른 곳에 저장할 수 있고, 즉, 상태 업데이트)는 이더리움 블록체인에서 발생하지 않으며, 사용자가 특정 상태를 정할 필요가 있다고 생각할 때만 상태를 이더리움으로 보내 확인합니다.한마디로: 네트워크가 단위 시간당 더 많은 트랜잭션에 대한 합의에 도달할 수 없다면 단일 트랜잭션의 의미를 개선하십시오.

고전적인 Layer-2 계획 "상태 채널"은 이 아이디어를 가장 철저하게 구현합니다. 채널에 참여하는 두 명의 사용자가 계약에 자금을 잠글 때 두 사용자 간의 트랜잭션은 나중에 체인으로 전송되지 않으며 다른 통신 도구를 사용하여 교환합니다. 메시지에 서명하고 채널 상태에 대한 합의에 도달합니다(따라서 얼마나 많은 메시지를 주고받든 얼마나 많은 상태 데이터를 형성하든 이더리움에 부담이 되지 않습니다). 상호작용이 필요(또는 일시적으로 한 번 정산이 필요)하므로 상호 인식 상태와 두 사람의 서명을 이더리움으로 보내고 이더리움은 계약 상태를 업데이트하며 이 상태에 따라 두 사람은 정착금.

Layer-2 솔루션을 계약의 디자인 패턴으로 간주하면 더 명확하게 알 수 있습니다. Layer-2 솔루션은 전역 상태를 활용하지 않기로 선택합니다. 또 다른 계약은 Layer-2 계약 내부에 어떤 상태가 있는지 실시간으로 알 수 없습니다(사용자 A\B\C가 보유한 금액). 이러한 상태는 체인에 없기 때문에 Layer-2 계약은 불가능합니다. 다른 계약과 결합.그럼에도 불구하고 Layer-2 솔루션은 더 빠른 트랜잭션 속도(확인된 중간 상태는 메인 체인의 상태만큼 안전하지 않지만), 낮은 처리 수수료 및 메인 체인 노드에 대한 부담 감소와 같은 매우 귀중한 것들을 교환했습니다. .그런데 지난 몇 년 동안 Layer-2 솔루션이 결실을 맺지 못한 이유는 무엇입니까? 롤업 계획이 나타나기 전에는 상태 채널 및 플라즈마를 포함한 다른 계획이 자체 계약에 잠긴 자금이 상태 저장 계약에 잠긴 자금만큼 안전하다는 것을 증명할 수 없었기 때문입니다(동결되거나 도난당하지 않음). 상태 채널 체계에서 블록체인을 항상 모니터링하지 않으면 상대방이 이전 상태를 메인 체인에 제출하여 돈을 "훔칠" 수 있으며, 플라즈마 체계에서는 종종 운영자에게 의존해야 합니다. 자신의 상태를 증명할 수 있으므로 운영자 자체가 방어하기가 매우 어렵습니다.이는 이더리움 메인넷에서 상태 계약을 사용하는 경험과는 완전히 다릅니다. 계약의 코드 위험을 제외하고 계약에 예치한 돈은 누군가가 51% 공격을 실행하여 거래를 취소하지 않는 한 도난당하지 않습니다. 자신의 자금을 인출하십시오. (이후 기사에서 롤업 솔루션이 이 문제를 어떻게 해결하는지 살펴보겠습니다.)(2) 단편화이더리움을 개선하고 이더리움의 처리량을 늘리는 또 다른 직관은 다음과 같습니다: 이더리움의 처리량은 각 전체 노드가 체인의 모든 트랜잭션을 처리해야 하기 때문에 제한됩니다. 그룹에서 서로 다른 트랜잭션을 개별적으로(병렬로) 처리하면 단위 시간당 전체 시스템의 처리량은 이러한 노드 그룹의 단일 그룹 처리 용량의 합과 같습니다. 증가하지는 않지만 전체 시스템의 처리량은 증가합니다(그리고 패킷이 미세할수록 처리량 승수는 커집니다). 이를 "샤딩"이라고 합니다.

샤드 아키텍처에 대한 흥미로운 질문은 정확한 정의입니다. 고전적인 비샤딩 블록체인 아키텍처에서 전체 노드는 (1) 모든 계산을 반복하고, (2) 모든 상태를 유지하고, (3) 모든 블록/트랜잭션을 전파해야 합니다. 어떤 사람들은 그 중 하나만 깨져야 단편화되었다고 생각하지만, 좀 더 엄밀한 관점에서 보면 세 개 모두 깨져야 이론적으로 도출된 처리량 향상 효과를 얻을 수 있습니다 6 . 다른 정의는 다른 효과를 가집니다. 여기서 내가 취하는 정의는 최소한 노드가 전체 시스템의 모든 상태를 유지할 필요는 없다는 것입니다.

그러나 더 흥미로운 또 다른 질문은 샤딩 아키텍처에서 요구하는 모든 프런트 엔드 기술이 실현될 수 있다면 이 아키텍처가 얼마나 의미가 있을 수 있는지입니다.이더리움 재단의 연구팀이 고안한 샤딩 아키텍처에서 전체 시스템의 상태는 여러 부분으로 나뉘고 각 부분은 병렬로 업데이트되며 슬라이스의 내부 상태입니다. 샤드 A의 컨트랙트 A'가 샤드 B에서 컨트랙트 B'를 호출하려고 하면 프로세서가 샤드 B의 상태를 소유한다고 가정할 수 없으므로 처리 결과는 샤드 B가 상태 업데이트를 완료한 후 를 반환해야 합니다. 결과적으로 교차 샤드 트랜잭션은 트랜잭션 처리에서 가장 견딜 수 없는 비용인 지연을 견뎌야 합니다. 요점은 이러한 지연을 금전적 비용으로 추상화할 수 없다는 것입니다. 샤드 B는 자신을 호출해야 하는 트랜잭션이 샤드 A에서 발생한 것을 모르기 때문에 신뢰할 수 있는 통신 계층이 이 트랜잭션을 브로드캐스트할 때까지만 기다릴 수 있습니다.단위 시간당 생성할 수 있는 가치가 높을수록 견딜 수 없는 지연이 발생하며, 이는 특정 DeFi 응용 프로그램 집중에 샤드가 있다고 가정하면 이러한 응용 프로그램이 교차를 통해 다른 샤드에서 처리를 예약하지 않는다는 것을 의미합니다. 전혀 의미가 없고 DeFi 애플리케이션의 지연 요구 사항을 충족할 수 없기 때문입니다. 마찬가지로 이것은 이 DeFi 애플리케이션에 의해 집계된 샤드 중 단일 샤드의 처리 능력이 해당 처리 능력의 상한선임을 의미합니다(단일 블록체인과 차이 없음). 깊은 산과 오래된 숲에 집을 짓고 도로를 건설하는 것은 대도시 사람들의 생활 공간 문제를 해결할 수 없습니다.(일부는 이러한 "유휴" 샤드 처리량이 더 많은 틈새 응용 프로그램에서 악용될 수 있다고 주장합니다. 저는 Layer-2 솔루션이 동일한 효과를 달성할 수 있지만 기본 계층에 대한 변경이 적고 더 안전하다고 생각합니다.)(3) 무국적무국적은 상태 데이터 확장 문제에 직접적으로 직면하는 유일한 업그레이드 방향입니다.현재 이더리움 프로토콜에서는 트랜잭션 자체가 방문하는 상태 정보를 가지고 있지 않기 때문에 트랜잭션을 처리하는 노드는 상태 전이 기능을 수행하기 위한 전제 조건으로 상태 데이터를 유지해야 합니다. 상태 데이터의 확장이 문제(노드에 대한 부담 증가)인 것은 바로 이 때문입니다.

상태 비저장의 핵심은 트랜잭션/블록 자체가 방문하는 상태 정보를 첨부하도록 하는 것이므로 블록 자체가 검증 가능하며 트랜잭션을 처리하는 노드가 상태를 가질 필요가 없습니다.

사실 stateless는 이더리움 블록의 구조를 변경하여 이더리움 블록의 검증 방식을 바꾸는 것입니다. 상태 데이터를 유지할 필요가 없으므로 하드 디스크를 읽고 쓸 필요가 없으며 블록 검증 속도도 빨라질 수 있습니다. 또한 각 노드는 상태 데이터를 전혀 유지하지 않거나 자체 필요에 따라 일부 계약의 상태 데이터를 유지할 수 있습니다.그러나 솔직히 말해서 무국적은 현재 많은 설계 문제에 직면해 있습니다. 구체적으로: (1) 상태 비저장은 액세스된 상태의 증명(증인)과 함께 블록/트랜잭션이 첨부되어야 합니다.데이터의 이 부분의 규모는 매우 클 수 있습니다.이더리움의 현재 블록 데이터 크기는 약 20-40KB입니다.그러나 , 증인 데이터의 크기는 MB 수준일 수 있음(액세스된 상태 볼륨의 크기에 따라 다름) (2) 모든 상태를 유지하는 노드만 증인을 모을 수 있으므로 일반 사용자에게 상태를 제공하는 사람 ? (실제로 이것은 이더리움 운영 가정의 변화로 볼 수 있습니다. 모든 풀 노드가 채굴에 참여할 수 있지만 상태 비저장이 실현된 후에는 참여할 수 없습니다.) (3) 트랜잭션의 가스 소비 가격은 어떻게 책정합니까? 특히 증인의 적시성 때문에 opcode를 기반으로 증인을 조립하는 데 얼마나 많은 계산이 필요한지 결정할 수 없습니다.이러한 어려움 때문에 이더리움의 전체 노드는 오랜 시간 동안 모든 상태를 유지하는 이 모드에서 실행해야 할 수도 있습니다. 그러나 무국적은 분명히 현재 이더리움 프로토콜 개선을 위한 가장 흥미로운 방향입니다. 이더리움의 핵심 문제에 직접적으로 직면하고 이 문제를 상향식으로 해결하려고 하기 때문입니다. 또한 이더리움 프로토콜에서 상태 데이터 사용에 대한 연구는 동기화 방법8과 같은 다른 연구 방향도 키웠습니다.저는 이더리움의 미래가 무국적은 아니더라도 무국적에서 영감을 받은 일종의 계획이라고 믿는 편향이 있습니다.(4) 롤업 방식롤업 방식은 Layer-2 방식으로 각 상태 업데이트에 사용되는 트랜잭션을 이더리움 블록체인에 게시하는 것이 특징입니다.다른 Layer-2 체계와 마찬가지로 롤업 체계도 상태를 오프체인에 저장하고 이더리움 노드가 계약의 새로운 상태를 계산할 필요가 없습니다. 즉, 제3자는 이러한 공개 데이터 및 공개 규칙에 따라 계약의 상태를 계산할 수 있습니다(Ethereum의 계약은 이러한 상태를 사용할 수 없지만).앞서 언급한 바와 같이 Lyaer-2 컨트랙트가 상태 계산을 이더리움 체인 밖으로 옮기고 자체 컨트랙트 상태를 모호하게 하면 사용자에게 위험이 발생합니다. 사용자는 Layer-2 컨트랙트의 운영자가 유효하지 않은 상태는 체인에 전송되어 블록체인에 의해 확정되지 않습니다.운영자가 이것을 할 수 있다면 사용자의 자금을 직접 훔치는 것과 같습니다.또한 사용자는 Layer-2 계약의 작동을 알지 못합니다. 투자자는 자신의 거래를 검열하지 않으므로 자신의 자금을 동결합니다.도난 자금 문제를 해결하는 방법에는 두 가지가 있습니다. 하나는 모든 상태 전환이 유효한지 확인하는 것입니다. 확인을 통과한 후에야 계약이 상태 루트를 업데이트할 수 있습니다. 이것이 zk-rollup의 아이디어이고, 또 다른 아이디어는 사람들이 계약 상태 루트 업데이트를 요청할 때 예치금을 첨부하도록 요구하는 것입니다. 만약 제출된 상태 루트가 유효하지 않습니다. 이 상태 루트를 보고하는 사람은 낙관적 롤업인 원래 제출자의 예치금을 얻을 수 있습니다. 그러나 후자의 아이디어에는 전제 조건이 있습니다. 내부 고발자는 상태 전환 전에 상태를 얻을 수 있는 방법이 있어야 합니다. 그렇지 않으면 전환에 대한 잘못된 증거를 생성할 방법이 없습니다.잠긴 자금 문제를 해결하는 유일한 방법은 "운영자"의 개념을 가능한 한 약화시켜 누구든지 Ethereum에 트랜잭션을 제출하여 Layer-2 계약의 상태를 업데이트할 수 있도록 하는 것입니다. 그러나 이것은 다시 질문으로 돌아갑니다. 제출자가 계약 상태를 가지고 있지 않은 경우 어떻게 그가 자신의 상태 액세스의 유효성을 증명하고 계약이 이를 해제하도록 할 수 있습니까?

마지막으로 롤업 솔루션은 "모든 상태 전환에서 일치하는 트랜잭션 데이터를 게시"하여 이 문제를 해결합니다. 따라서 롤업 계약이 체인의 상태를 공개하지 않더라도 롤업 계약 사용자를 포함한 누구나 이러한 공개 트랜잭션 패키지를 기반으로 롤업 계약의 내부 상태를 재구성할 수 있습니다. 즉, 적절하게 설계된 경우 롤업 계약의 자금은 이더리움 블록체인의 상태 저장 계약(즉, 현재 우리가 일반적으로 사용하는 계약)만큼 안전할 수 있습니다!

zk-rollup을 예로 들면, 온체인 검증 프로그램은 Maker DAO가 허가 없이 DAI를 압수할 수 없는 것처럼 롤업 계약이 잘못된 상태 루트를 업데이트할 수 없도록 보장합니다. 건설 방법을 사용하면 언제든지 체인의 계약으로 상태 전환을 직접 시작하여 자신의 돈을 인출할 수 있습니다. 이는 정상적인 상태 저장 계약과 정확히 같습니다. 51% 공격 없이 롤업 계약 상태를 롤백할 방법이 없으며 지속적인 51% 공격 없이 돈을 돌려받는 것을 막을 방법이 없습니다.낙관적 롤업은 일부 암호화 경제 가정에 의존하므로 약간 더 약합니다. 51% 공격 롤백 상태 외에도 공격자는 일정 기간 동안 지속되는 51% 검토 공격을 통해 계약에 잘못된 상태 루트를 주입할 수 있습니다. 계약의 최신 상태를 계산한 사람 중 누구도 오류를 관찰하지 않을 것이라는 데 베팅하십시오(확률은 매우 낮음). 그러나 Optimistic-rollup은 강력한 양육권을 제공할 수 있으며 언제든지 돈을 돌려받을 수 있습니다.