매직 레이어2: 모듈형 엔드게임은 새로운 '레이어1' 포털?

출처: Chain View

시장에 '병렬 EVM'이라는 새로운 화두가 등장했고, 레이어2는 '세분화된' 롤업이라는 새로운 패러다임을 가능하게 하는 매우 흥미로운 솔루션으로, 솔라나가 '마법의 총알'이라고 해도 과언이 아닐 정도입니다. 제 생각에 병렬 ERP는 "세분화된" 롤업이라는 새로운 패러다임을 달성하는 가장 좋은 방법입니다. 제 생각에 병렬 EVM은 롤업의 고도로 "모듈화된" 표현일 뿐이며, DA가 타사의 공격을 받은 후 VM 실행 계층이 다시 무너졌고 향후 레이어2가 재정의될 것입니다. "EVM"의 단일 스레드 실행 모델.

이 모델은 트랜잭션을 차례대로 순차적으로 처리하고 확인하도록 규정하고 있어 트랜잭션 처리 속도, 블록 아웃 시간, 트랜잭션 처리량에 직접적인 영향을 미치며 메인 이더넷 네트워크에서 가스가 높고 혼잡한 주요 원인입니다. 또한 이더리움이 단일 스레드로 설계된 이유에는 역사적인 한계가 존재합니다. 이더리움의 거래는 분산된 독립 노드에 의해 검증되고 실행되기 때문에 잔액, 스마트 컨트랙트 코드 등 모든 주소의 데이터가 서로 다른 노드 간에 일관된 상태를 유지해야 하며, 동시에 동일한 자산의 이중 지불 가능성이 없도록 보장해야 합니다.

이것은 트랜잭션이 순차적으로 대기해야 한다는 것을 의미합니다. 병렬 트랜잭션이 있으면 노드 간에 데이터 동기화 오류가 발생할 수 있으며, 결정적으로 심각한 이중 지불 거래가 발생할 수 있습니다. 일반적인 설명 : 은행에는 서비스 창구가 하나 뿐이고, 고객 인출은 예금 인출뿐만 아니라 대출 및 기타 비즈니스이든 상관없이 순서대로 대기해야하며, 고객은 다음 작업을 시작하기 전에 비즈니스를 완료해야하며, 장점은 각 작업에 대한 은행의 계정 시스템이 정확하게 기록되지만 고객 대기 시간이 길어진다는 것입니다.

은행에서 둘 이상의 서비스 창구를 열면 고객은 다른 비즈니스를 처리 할 창을 선택할 수 있으며, 다음과 같이 될 것입니다. 한 계좌에서 동시에 인출을 시도하는 두 개의 창이 있는데, 창 사이의 계좌 시스템이 제때 조정되지 않으면 이중 지출로 이어져 분명히 효율성이 향상되지만 복잡한 부기 로직으로 인해 회계 시스템에 압력을 가할 것입니다. 레이어1 독립 체인 시나리오에서는 체인 하위 레이어가 병렬 처리를 지원하면 문제가 해결됩니다. 솔라나는 계산과 저장 상태가 분리되어 있기 때문에 사용자로부터 여러 트랜잭션을 수신 한 후 VM이 이러한 트랜잭션을 정렬 한 다음 독립 스토리지 시스템 상태 데이터를 호출하여 이러한 트랜잭션의 상태간에 충돌이 있는지 감지하고 충돌이 없으면 트랜잭션을 블록에 패킹하고 충돌이 없으면 블록에서 충돌하는 트랜잭션을 제외하고 충돌이 없으면 블록에서 충돌하는 트랜잭션을 제외하고 충돌이 없으면 블록에서 충돌하는 트랜잭션을 제외합니다. 충돌이 발생하면 충돌하는 트랜잭션이 이 블록에서 제외됩니다.

반면 이더리움의 스토리지 상태는 실시간으로 계산되며, 각 트랜잭션은 이전 트랜잭션이 완료될 때까지 기다렸다가 상태를 업데이트해야 하므로 트랜잭션이 패키징될 때까지 기다리기 전에 트랜잭션을 선별하는 것이 불가능하여 병렬 처리의 가능성이 제한됩니다. 레이어2 롤업 체인 시나리오에서 병렬 처리를 달성하려면 스테이킹을 멀리하는 것도 비슷합니다. 솔라나가 POH 타임스탬프를 기다리는 동안 트랜잭션을 계산하고 저장소 상태를 감지하는 것은 롤업 체인이 시퀀서에서 트랜잭션을 처리한 다음 메인 네트워크로 일괄 처리하는 것으로 생각할 수 있습니다.

이제 트랜잭션을 배치하기 전 레이어2에서 시간 순서대로 트랜잭션에 대한 논스를 큐에 대기시킨 후 메인넷에 순서대로 배치하는데, 멀티스레딩에서 이를 어떻게 처리할 수 있을까요?

1) AA 계정 추상화 모델에 따르면 계정 상태에서 동시에 여러 트랜잭션을 시작할 수 있는데, 예를 들어 두 개의 전송이 동시에 실행되면 AA 스마트 컨트랙트는 논스를 부여하고 순차적으로 실행해야 하는데, 하나는 전송이고 하나는 승인이라면 논스의 제한 없이 보다 유연하게 병렬로 처리할 수 있습니다. AA 계정 모델에서는 각 계정이 트랜잭션 처리 로직을 사용자 정의한 다음 논스를 사용하여 높은 동시성을 달성할 수 있습니다.

2) 시퀀서 트랜잭션은 "미세 조정" 처리가 가능합니다. 예를 들어 레이어2 트랜잭션이 시퀀서에 제출되면 시퀀서는 트랜잭션 로직을 빠르게 감지하고 다음과 같이 미세 조정된 정렬 및 선별 작업을 수행할 수 있습니다. 동일한 계정이 두 개의 트랜잭션을 시작하면 후자는 제외하고 다음 배치를 기다려야 하며, 동일한 계정이 서로 다른 성격의 두 가지 작업을 시작하면 동시에 블록에 배치할 수 있습니다.

단순하게 들리시나요? 그러나 사실 상황은 결코 그렇지 않습니다. 디파이 시나리오를 예로 들어 시퀀서가 트랜잭션을 세밀하게 관리하려면 두 가지 주요 과제가 있습니다.

1) 거래 데이터를 실시간으로 파싱하고, 스마트 컨트랙트 호출 방법과 매개 변수의 수신 데이터를 이해하고, 디파이 공통 스테이킹을 예로 들어 토큰 전송, 상태 업데이트를 포함하는 스테이킹 작업을 수행합니다, 서약 기간, 잠재적 보상 계산 등이 포함됩니다. 다수의 사용자가 동시에 일부 스테이킹 트랜잭션을 입력하는 경우, 또 스테이킹된 토큰을 이전하는 트랜잭션이 있는 경우, 그리고 Oralce 가격 요소 등이 복잡한 경우, 시퀀서가 이를 제때 파싱하고 처리하지 못하면 한 단계의 오류가 심각한 사고로 이어질 수 있습니다.

2) 탈중앙화를 보장하기 위한 시퀀서, 현재 레이어2 시퀀서는 권한이 너무 크다는 전제하에 트랜잭션을 일괄 처리하고, 시퀀서 탈중앙화 문제를 해결하지 못하면 "정제" 롤업을 하는 것은 시퀀서에게 더 많은 권한을 주는 것과 같습니다. 시퀀서에게 더 많은 권한을 주는 것과 같습니다. 시퀀서가 악의 한가운데에 있다면 가짜 거래, 노골적인 MEV 클립, 심지어 오라클 청산에 대한 악의적인 조작 등이 번식할 것입니다.

최근 메티스는 표면적으로는 탈중앙화를 달성하기 위해 시퀀서만을 추구하지만, 더 깊이 들여다보면 미래의 시퀀서가 기본적인 합의 전제를 잘 롤업할 수 있도록 하기 위한 것입니다. 물론 시퀀서가 고도로 정제된 롤업 트랜잭션 집계 및 처리를 수행하기 위해 현재는 여전히 일종의 개념, 좋은, AA 계정 추상화, 이 개념에 대한 개방형 아이디어의 블록 체인 전체 모듈식 조합이 전제 조건을 제공하기 위해 실제로 실행에 옮기는 것입니다.

위.

그리고 앞서 언급했듯이 레이어2의 전반적인 모듈화는 점점 더 모듈화되고 있으며, OP 스택의 프레임워크에 ZK 기술을 내장하여 프라이버시 확장을 달성하고, 오리지널 이더 DA를 타사 DA인 셀레스티아로 변환하여 비용을 절감하고, 가스 수수료의 전통인 이더를 점차적으로 변환하여 레이어2 토큰의 유틸리티 권한을 부여합니다. 심지어 레이어2는 트랜잭션을 일괄 처리하여 다른 가상머신 실행 환경에 제출할 수 있으며, 트랜잭션은 솔라나와 이더리움 등에서 처리될 수 있습니다.

이 시점에서 레이어2는 더 이상 이더의 레이어2가 아니고, 솔라나가 이더의 레이어2가 될 수 있으며, 레이어2의 정의조차 마술처럼 바뀌는 완전히 새로운 패러다임이 등장하게 됩니다.

대담하게 상상해 보세요. 이제 레이어2는 고액 거래 처리 기능을 통합하는 엔트리 레벨의 '레이어1'이 되고, 이더와 솔라나, 그리고 이전의 레이어1은 자산 결제와 보안을 담당하는 새로운 '레이어2'가 됩니다. 레이어2는 결코 경직된 개념이 아니며, 거래의 대규모 동시 처리를 해결하기 위한 레이어2 플랫폼은 시장 그룹의 미션의 점진적인 사용자를 유치하기 위해 항상 존재해 왔습니다.

미션이 달성되면 모듈화 이념에 따라 이더리움 레이어1의 정통성이 깨질 뿐만 아니라 DA 데이터 가용성, VM 실행 레이어, 상호운용성 통신 상호작용까지 전체 체인이 레이어2의 인프라가 되어 대량 채택을 실현할 것이며, 이때 레이어2는 더 이상 레이어1을 보완하는 것이 아니라 레이어2의 인프라가 되어 대량 채택을 실현하게 될 것입니다.