롤업 분류기에 대한 전체 안내서: 개념, 상태 및 공유 분류

편집 원본: 0x11, Foresight News

편집 원본: 0x11, Foresight News

Shared Sequencer는 비약적으로 진화하고 있으며 이것이 무엇이며 왜 존재하는지에 대한 심층 분석이 필요한 시점입니다. 이 기사의 분석 대상은 낙관적 롤업으로 제한되며 ZK 팔로워가 와서 조언을 제공하는 것을 환영합니다.

분류기란 무엇입니까?

시퀀서는 낙관적 롤업에서 반신뢰 역할입니다. 트랜잭션은 메인 체인 자체에서 정렬할 수 있지만 이는 경제적이지 않으며 사용자는 롤업 트랜잭션에 해당하는 메인 체인 트랜잭션을 별도로 제출하고 메인 체인에서 수수료를 지불해야 합니다. 주문자는 롤업 트랜잭션이 단일 메인체인 트랜잭션을 공유하도록 허용하여 사용자의 이러한 문제를 해결합니다.

분류기는 오프체인에서 여러 사용자 트랜잭션을 집계하여 메인 체인의 정렬을 보완하고 단일 트랜잭션 모음으로 메인 체인에 제출하며 트랜잭션 비용은 사용자 간에 공유됩니다. 또한 분류기는 트랜잭션 컬렉션을 압축하여 메인 체인 데이터 가용성 비용을 추가로 절감할 수 있습니다. 자율적으로 주문하는 사용자는 주문자에게 의존하는 사용자보다 롤업에 포함된 거래에 대해 더 많은 비용을 지불합니다.

그러나 분류기는 트랜잭션 컬렉션에서 트랜잭션 순서를 제어할 수 있습니다. 사용자 거래를 포함하지 않도록 선택할 수 있으므로 사용자가 스스로 분류하고 더 높은 메인 체인 비용을 지불하도록 할 수 있습니다. 재정렬 및 ​​삽입 추출을 통해 트랜잭션 컬렉션에서 MEV를 추출할 수도 있습니다. 실제로 롤업에 대한 우선 쓰기 액세스 권한이 있습니다. 주문자가 계약과 상호 작용할 수 있기 때문에 절대적으로 신뢰할 수 있는 거래만 온체인 메커니즘에 의해 안정적으로 시행될 수 있으며 신뢰할 수 없는 거래는 강제로 주문할 때 실패할 가능성이 높습니다.

이렇게 하면 Collator가 Rollup 사용자의 반신뢰 당사자가 됩니다. 주문자는 사용자가 롤업에 액세스하는 것을 막을 수는 없지만 사용자의 액세스를 지연시키고 사용자에게 추가 요금을 부과하며 사용자 거래에서 가치를 추출할 수 있습니다. 분권화를 통해 분류기의 동작을 더욱 제한하는 것이 적극적입니다.연구 주제。

정렬과 실행의 차이점은 무엇입니까?

분류기는 메인 체인 분류를 보완하는 것으로 롤업 상태를 계산하지 않으며 실제로 유효하지 않은 트랜잭션을 분류하도록 선택할 수 있습니다. 롤업 노드는 정렬 데이터를 구문 분석 및 정리하고 롤업에 대한 유효한 기록을 내보내고 기록을 실행하여 최신 상태를 생성해야 합니다. 시퀀서는 이 프로세스에서 완전히 벗어났습니다.

그래도 친구로서Fred내가 계속 상기하듯이 트랜잭션이 순서대로 배열되면 그 결과는 결정론적입니다. 이것은 모든 롤업 노드가 분류기에 의해 생성된 순서대로 결과에 동의한다는 것을 의미합니다. 롤업은 알려진 기록에서 올바른 상태를 가집니다. 노드가 이 상태를 찾으면 한 명 이상의 제안자가 이를 메인 체인의 롤업 계약에 제출합니다.

이론적으로 모든 노드는 제안자가 될 수 있으며 권한이 필요하지 않습니다. 제안자는 채권과 함께 주 체인에 상태를 커밋합니다. 사기 증명이 유효하지 않은 상태로 판명되면 보증금이 몰수됩니다. 계약은 타이머가 만료된 후 증명을 수락하고 그 안에 포함된 사용자 트랜잭션은 메인 체인에서 실행됩니다. 실행 노드는 사기 게임을 통해 제안자의 정직성을 보장하며 실행 노드를 "롤업 전체 노드" 또는 "검증자"라고 부르는 경향이 있습니다.

즉, 주문이 메인 체인에 커밋되면 상태는 최종적이고 변경할 수 없게 됩니다. 제안자는 롤업에서 메인 체인까지 자산 브리지의 이익을 유지하기 위해 롤업 계약에 대한 최종 상태를 계산하고 보고합니다. 제안자는 상태를 생성하지 않고 계산하고 증명할 뿐입니다. 롤업 컨트랙트는 롤업을 생성하거나 확정하지 않으며 단지 제안자로부터 롤업 상태를 가져옵니다.

주문과 제안을 분리하는 이유는 무엇입니까?

이것은 복잡한 문제입니다. 근본적으로 그들은 그들 자신이 분리되어 있기 때문에 분리되어 있다. 동어반복처럼 들릴지 모르지만 모두가 깨닫기까지는 오랜 시간이 걸린 것 같다. 우리는 Rollup 아이디어의 역사가 Plasma 및 상태 채널에서 수년에 걸쳐 구불 구불 해 왔다는 것을 되돌아보고 봅니다. Bitcoin 기반 proto-Rollup 초기에는 주문자가 없었고 사용자는 단순히 거래를 메인 체인에 게시했습니다. 그 후, 이 디자인은 수년 동안 사라졌습니다.Barry작업이 다시 나타납니다. Barry와 Celestia 사이에서 Rollup의 연구는 Rollup 브리지와 메인 체인의 상호 작용에 중점을 두었습니다. Sovereign Rollup 전에는 아무도 우리가 실제로 더 나은 Mastercoin을 만들고 있다는 사실조차 깨닫지 못했습니다.

출처는 제쳐두고 시퀀서는 사용자의 거래 비용을 최소화하는 특정 문제를 해결합니다. 그러나 이 프로세스는 새로운 문제를 야기합니다. 분류기는 동일한 트랜잭션에 대해 동시에 여러 분류 결과를 생성할 수 있습니다. 정렬이 전적으로 메인 체인에서 수행되는 경우 단일 표준 정렬이 있지만 사용자 트랜잭션 수수료는 더 비쌉니다. Rollup에서 사용자 경험을 개선하기 위해 분류기를 사용하기로 했습니다.

제안자가 여러 명이므로 주문자가 많다고 가정합니다. 분류자는 충돌하는 순서를 제출할 수 있으며 이제 우리는 메인 체인에서 특정 분류 배치를 "표준화"하는 메커니즘이 필요합니다. 현재 롤업은 하나의 구체적이고 알려진 반신뢰 주문자를 통해 이 작업을 수행합니다. 단일 분류기를 선택하면 분산형 분류기가 도착할 때까지 이 문제를 해결할 수 있습니다. 다수의 제안자를 원하지만 단 한 명의 주문자만 원하기 때문에 이 두 역할은 분리되어야 합니다.

데이터 종속성은 또 다른 중요한 이유입니다. 제안자는 주문이 필요하지만 주문자는 상태가 필요하지 않습니다. 제안자는 주문자의 작업 결과에 의존하지만 주문자는 제안자에게 의존하지 않습니다. 데이터 종속성은 단방향이므로 역할과 단일 역할에 집중할 수 있는 행위자 간에 경계를 그려야 합니다.

원래 질문에 답하기 위해 제안자와 주문자는 서로 분리되어 있기 때문에 분리합니다. 제안자는 주문자의 다운스트림에서 작업합니다. 롤업은 주문자에게 신뢰와 권한을 부여하지만 제안자는 평범한 작업자입니다.

주문자, 제안자 및 유효성 검사기의 상태

Arbitrum과 Optimism은 두 가지 일반적인 ORU 체계입니다. 그들 사이의 주요 역할을 간략하게 소개하고 싶습니다. 코드는 포함되지 않고 사양과 문서만 포함됩니다. 낙관론에 대한 논의는 (아직 배포되지 않은) Bedrock 디자인으로 제한됩니다.

Arbitrum

Arbitrum collator는 사용자 트랜잭션을 일괄 처리하고 압축하는 것 외에도 전체 노드를 실행합니다. 거래는 거래가 주문될 때 신뢰할 수 있는 WebSocket 피드를 생성하는 주문자에게 직접 전송됩니다. Arbitrum은 이 피드를 "소프트" 확인 소스로 사용합니다. 분류기는 분류 결과에 대한 약속을 하고 사용자는 일반적으로 해당 분류에 의존할 수 있습니다. 노드, MEV Seeker 또는 기타 액터는 이 피드를 사용하여 롤업 상태를 미리 계산할 수 있습니다.

분류기는 주기적으로 분류된 압축 트랜잭션을 메인 체인에 게시합니다. 메인 체인의 최종화는 롤업의 "하드" 확인을 나타냅니다. 메인 체인에서 주문이 설정되면 주문의 모든 트랜잭션이 최종 상태가 되고 결과 상태가 최종 상태가 되는 Arbitrum 체인의 불변 부분이 됩니다.

당연히 시퀀서가 트랜잭션의 순서를 정하기 때문에 우선 쓰기 액세스 권한을 갖습니다. 분류기는 분류되는 항목을 제어할 수 있으므로 롤업 기록에서 트랜잭션 순서를 지정할 수 있습니다. 물론 사용자는 다음을 사용할 수 있습니다.delayed inbox트랜잭션의 필수 포함. Seeker는 WebSocket 트랜잭션 피드의 대기 시간을 최소화하기 위해 많은 노력을 기울였으므로 Arbitrum 트랜잭션을 정렬하기 위해 강력한 MEV 시장을 형성할 가능성이 높습니다.

승인된 Arbitrum 제안자는 13명이며, 각 제안자는RBlockETH는 . 사용자는 롤업 전체 노드를 실행하지 않고 롤업에 대한 최종 결정을 내리기 위해 지분의 일정 비율에 의존하도록 선택할 수 있습니다. Arbtirum 유효성 검사기는 사기를 식별할 수 있지만 제안자만이 사기 증명을 통해 약속의 유효성에 이의를 제기할 수 있습니다. 실제로 제안자만이 완전한 검증자가 될 수 있습니다.

정의는 시퀀서처럼 눈이 멀어 검을 들고 다녀야 합니다.

Optimism

Arbitrum과 마찬가지로 Optimism collator는 사용자 트랜잭션을 일괄 처리하고 압축하는 것 외에도 전체 노드를 실행합니다. 거래는 주문자에게 직접 전송되며 주문 시 신뢰할 수 있는 사전 확인이 생성됩니다. Optimism 사용자는 이러한 확인을 최종 소프트 확인의 소스로 사용할 수 있습니다. 분류기는 주문에 대한 약속을 하고 사용자는 일반적으로 해당 주문에 의존할 수 있습니다. 노드, MEV Seeker 또는 기타 액터는 이러한 확인을 사용하여 롤업 상태를 미리 계산할 수 있습니다.

분류기는 주기적으로 분류된 압축 트랜잭션을 메인 체인에 게시합니다. 메인 체인의 최종화는 롤업의 "하드" 확인을 나타냅니다. 메인 체인이 시퀀스를 설정하면 Optimism 체인의 역사에서 변경할 수 없는 부분이 됩니다. 그 안에 정렬된 모든 트랜잭션이 최종 상태가 되고 결과 상태도 최종 상태가 됩니다.

당연히 시퀀서가 트랜잭션 순서를 설정하므로 먼저 쓰기 액세스 권한을 갖습니다. 분류기는 분류되는 항목을 제어할 수 있으므로 롤업 기록에서 트랜잭션 순서를 지정할 수 있습니다. 물론 사용자는 트랜잭션을 메인 체인에 강제로 포함시킬 수 있습니다. MEV 경매 개념의 창시자로서 Optimism 거래 주문을 위한 강력한 MEV 시장이 형성될 것으로 보입니다.

낙관주의는 1면허 제안자요약

요약

공유 분류기

공유 분류기

분류기에 대한 새로운 이해를 바탕으로 제가 정말로 이야기하고 싶은 공유 분류기로 넘어갑시다. 롤업이 동일한 분류기를 공유하면 어떻게 됩니까?

다른 롤업은 무엇을 의미합니까?

빌리다벤의 정의, 우리는 Rollup을 상태, 상태 전이 기능 및 증명 시스템으로 생각해야 합니다. 롤업에는 계약과 계정이 있으며 트랜잭션을 처리하여 해당 계약과 계정을 업데이트하는 가상 머신이 있는 반면, 비주권 롤업에는 메인 체인에 대한 브리지를 실행하는 증명 시스템이 있습니다. 각 구성 요소는 여러 디자인으로 제공되며 어느 정도 혼합 및 일치될 수 있습니다.

그러나 일부 구성 요소는 다른 구성 요소보다 더 동일합니다. 전반적으로 상태를 체인의 본질로 생각해야 합니다. 체인은 상태를 변경하지 않는 경향이 있습니다. 결국 Ethereum 개발자는 가상 머신을 여러 번 변경하고 합의 메커니즘을 여러 번 변경했지만 상태는 한 번만 변경했습니다. 상태는 Rollup이며 이를 지원하기 위해 가상 머신과 증명 시스템이 존재합니다. 따라서 서로 다른 롤업은 서로 다른 상태를 갖습니다. 증명 시스템 또는 STF를 공유할 수 있지만 두 롤업은 동일한 상태를 공유할 수 없습니다.

추출, 검사 및 필터링

롤업은 메인 체인 기록에서 상태를 가져옵니다. 이를 위해 각 롤업은 "가져오기" 기능을 정의해야 합니다. 추출 기능은 메인 체인 히스토리를 롤업 히스토리와 비롤업 히스토리로 나눕니다. STF는 롤업 기록을 처리하여 롤업 상태를 생성합니다. 실제로 가져오기 기능은 Rollup이 메인 체인을 확인하는 "렌즈"가 됩니다.

롤업을 사용하면 분류기가 다음 함수 실행의 출력을 추출하도록 선택할 수 있습니다. 분류기는 롤업 노드가 다음에 보고 처리할 데이터를 선택하므로 STF의 작업 및 다음 상태를 어느 정도 제어할 수 있습니다.

공유 분류기

공유 분류기

공유 분류기는 둘 이상의 롤업 추출 기능에 대한 입력을 제공합니다. 따라서 STF의 입력을 제어하여 둘 다에 대한 새로운 기록을 설정합니다. 각 롤업에 대해 개별적으로 또는 둘 다에 대해 이 작업을 수행할 수 있습니다. 히스토리가 개별적으로 설정되면 비공유 분류기와 똑같이 작동합니다.

그러나 동시에 두 롤업에 대한 새 기록을 생성할 때 공유 시퀀서는 두 롤업의 기록을 원자적으로 "연결"하여 일부 추가 기능을 행사할 수 있습니다. 시퀀서는 각 롤업에 대한 시퀀스를 동시에 생성하고 둘 다 승인되거나 모두 승인되지 않도록 합니다. 이를 통해 orderer는 두 체인의 히스토리를 제어할 수 있으므로 Rollup의 다음 상태를 어느 정도 제어할 수 있습니다.

원자적 포함(원자적 실행 아님)

이 시점에서 저는 분류기가 생산하는 분류에 대해 상당한 재량권을 행사할 수 있다는 점을 다시 한 번 강조해야 합니다. 즉, 사용자는 공유 주문자를 사용하여 메인 체인과 상호작용하지 않고 여러 롤업에서 거래할 수 있지만 주문자에게 반드시 의존하여 해당 거래 간의 특정 관계를 생성할 필요는 없습니다. 공유 분류기 지지자들은 사용자가 포함의 원자성을 지정할 수 있는 새로운 구조를 구상합니다. 즉, 분류기는 공유 강제 주문 메커니즘을 통해 동시에 여러 롤업의 트랜잭션 집합을 강제로 정렬할 수 있습니다. 이를 통해 사용자는 이러한 모든 원자 트랜잭션이 롤업 기록에 포함되거나 전혀 포함되지 않도록 할 수 있습니다.

보기만큼 좋지는 않습니다. 오류가 없는 트랜잭션만 순서 지정을 적용할 수 있으므로 오류가 없는 트랜잭션 집합만 원자적으로 포함될 때 원자적으로 실행되도록 보장됩니다. 앞서 말했듯이 봉쇄와 실행은 별개입니다. 롤업은 포함 후 실행 전 필터 기능을 통해 유효하지 않은 트랜잭션을 걸러냅니다. 주문자가 사용자의 원자 집합을 가져오고 트랜잭션이 실패하거나 무효화된다고 가정합니다. 트랜잭션은 정렬 후 필터링되며 실행되지 않습니다. 이는 관련된 모든 트랜잭션이 오류가 없는 경우가 아니면 원자 포함이 원자 실행을 보장하기에 충분하지 않음을 의미합니다.

특히 간단한 전송 및 인출은 원자적으로 수행할 수 있지만 스왑 또는 DeFi 상호 작용과 같이 오류가 발생하기 쉬운 것은 수행할 수 없습니다. 불행하게도 대부분의 고가치 상호 작용은 오류가 발생하기 쉬운 하나 이상의 트랜잭션으로 구성되므로 원자적 포함이 작동하도록 만드는 것이 어려워 보입니다. 이는 공유 시퀀서를 통한 교차 롤업에 대한 DeFi 구성 가능성을 효과적으로 배제합니다. 공유 주문자는 만병통치약이 아니며 사용자 자산은 프로세스가 끝날 때까지 비동기 교차 체인 모델에 잠길 수 있습니다.

롤업 컴포지션의 원자적 실행

메인 체인에 주문을 게시하기 전에 주문자가 신뢰할 수 있는 실행 보증을 제공하는 방법에 대해 어떻게 이야기했는지 기억하십니까? 여러 롤업 시스템에 대해 동일한 작업을 수행하는 공유 시퀀서를 상상할 수 있습니다. 공유 주문자는 각 롤업에 대해 전체 노드를 실행하고 이를 사용하여 트랜잭션의 성공 여부를 결정할 수 있습니다. 그런 다음 모두 성공하지 못하는 원자성 트랜잭션 집합의 순서를 생성하지 않을 것이라고 약속할 수 있습니다.

물론 이 시스템은 신뢰할 수 있습니다. 당신은 분류기가 거짓말을 하지 않을 것이라고 믿을 것입니다. 지금쯤이면 "시퀀서의 동작을 제한하여 신뢰할 수 없는 시스템으로 전환할 수 있을까요?"라고 생각하고 계실 것입니다. 대답은 "예, 하지만"이라고 말할 수 있어서 기쁘고/슬프고/혼란스럽습니다. 예, 하지만 우리가 하는 방식은 각 롤업의 STF를 결합하여 결합된 모든 롤업 트랜잭션을 실행하는 단일 STF를 만드는 것입니다. 즉, 모든 롤업 간에 모든 가상 머신을 원자성으로 만들어야 합니다. 이는 동일한 롤업으로 만드는 것과 같습니다. 예, 여러 롤업을 하나로 결합하여 신뢰할 수 없는 원자 실행을 달성할 수 있습니다. 이것은 좋은 생각일 수 있지만1 실현 가능성이 의심됩니다.

우발적 관계의 원자적 실행

나는 이것에 대해 다른 곳에서 썼고 또 다른 확실한 옵션은 트랜잭션과 롤업 상태 사이의 명시적인 우발적 관계를 통합하는 것입니다. 이는 원격 롤업에 대한 신뢰를 기반으로 상태 루트를 계산하고 제안해야 하기 때문에 우발 상황을 평가하는 부담을 제안자에게 전가합니다. 하지만 필터 기능을 반복적으로 적용하면 간단하게 할 수 있을 것 같습니다. 우발 상황이 특정 트랜잭션 및 블록 내에서 모호하지 않다고 가정하면 필터를 두 번 실행할 수 있습니다. 한 번은 예측된 상태가 유효하다고 가정하고 한 번은 예측된 상태가 유효하지 않다고 가정합니다. 이것은 필터 함수의 2^n 평가 비용으로 n 예측 상태로 확장될 수 있습니다.

결론적으로

결론적으로

시퀀서는 롤업 기록을 설정하고 예정된 상태로 똑딱거리는 것을 지켜보는 시계 제작자의 천재입니다. Optimism과 Arbitrum 사이에는 큰 차이가 없지만 둘 사이에는 보안상의 차이가 있습니다. 분류기가 무엇을 하는지 아무도 모릅니다. 공유 분류기는 원자 포함을 수행할 수 있지만 원자 실행은 수행할 수 없으며 원자 포함은 롤업 구성 또는 일부 다른 실행 메커니즘 없이 원자 실행에 통합될 수 없습니다. 원활한 상호 운용성을 위해 시퀀서를 공유하는 것에 대한 이 모든 자랑은 정크 과학입니다.