이더리움의 멀티체인 개발은 어디로 가는 걸까요? 아마도 Polkadot이 참고 답변을 드릴 수 있을 것입니다.

원본 텍스트: Starknet 및 Madara 앱 체인용 공유 시퀀서

저자: Apoorv Sadana

편집 : 오데일리 어때요?

점점 더 많은 L2 및 애플리케이션 체인이 결제 계층으로 이더리움에 의존하게 되면 여러 체인 간의 상호 운용성과 각 체인의 분산 정도가 특히 중요해집니다.

이 기사에서는 다양한 애플리케이션 체인이 검증자 세트를 공유하여 분산화를 달성하고 주문 엔진과 롤업 엔진을 통해 트랜잭션 주문 및 실행을 처리할 수 있도록 하는 공유 시퀀서의 개념에 대해 설명합니다.

그러나 공유 시퀀서와 Polkadot의 멀티체인 설계 아키텍처는 매우 유사하므로 Polkadot의 기성 기술을 이더리움 생태계에 도입하여 이더리움의 멀티체인 개발 프로세스를 개선할 수 있습니까?

다음은 Odaily에서 편집한 것입니다.

100개의 앱 체인은 어떻게 되나요?

현재 100개의 서로 다른 애플리케이션 체인이 이더리움에 정착하는 미래에 있다고 가정해 보겠습니다. 이로 인해 발생하는 문제를 해결해 보겠습니다.

분산화된 단편화

각 애플리케이션 체인은 자체적으로 분산화 문제를 해결해야 합니다. 이제 애플리케이션 체인의 분산화는 L1만큼 필요하지 않습니다. 주로 보안을 보장하기 위해 L1에 의존하기 때문입니다. 그러나 생존 가능성을 보장하고 검열에 저항하며 독점 이점(예: 높은 수수료)을 방지하려면 여전히 분산화가 필요합니다. 그러나 각 애플리케이션 체인이 분산 문제를 해결하기 위해 자체적인 방식을 채택한다면 이는 검증자 세트의 단편화로 이어질 것입니다. 각 애플리케이션 체인은 새로운 검증인을 유치하기 위해 경제적 인센티브를 개발해야 합니다. 또한 검증인은 실행하려는 클라이언트를 선택해야 합니다. 이는 개발자가 자신의 애플리케이션 체인을 시작하는 데 큰 진입 장벽을 만듭니다(단지 단일 트랜잭션인 스마트 계약을 배포하는 것과 비교할 때).

구성 가능성

구성 가능성은 기본적으로 애플리케이션 간의 상호 작용을 의미합니다. Ethereum이나 Starknet에서 이는 단순히 다른 스마트 계약을 호출하는 것을 의미하며, 그 밖의 모든 것은 프로토콜 자체에서 처리됩니다. 그러나 애플리케이션 체인에서는 이것이 더욱 어려워집니다. 다양한 애플리케이션 체인에는 자체 블록과 합의 메커니즘이 있습니다. 다른 애플리케이션 체인과 상호작용을 시도할 때마다 합의 알고리즘과 최종성 보장을 주의 깊게 검토하고 그에 따라 크로스 체인 브리지를 설정해야 합니다(체인에 직접 또는 L1을 통해). 다양한 디자인의 10개 앱 체인과 상호 작용하려면 이 작업을 10번 수행해야 합니다.

개발 경험

탈중앙화와 브리징 문제를 해결하는 것은 쉽지 않습니다. 모든 애플리케이션 체인이 이러한 문제를 해결해야 한다면 일반 스마트 계약 개발자가 자체 애플리케이션 체인을 구축하는 것이 매우 어려워질 것입니다. 또한 각 애플리케이션 체인이 이러한 문제를 자체 방식으로 해결하려고 시도함에 따라 곧 서로 다른 표준을 따르는 서로 다른 체인을 보게 될 것이며 이로 인해 새로운 프로젝트 당사자가 생태계에 참여하기가 더 어려워질 것입니다.

공유 분류기가 이 문제를 해결할 수 있습니다

앱 체인 공간을 따라가다 보면 공유 시퀀서라는 용어를 들어보셨을 것입니다. 위의 문제를 해결하기 위해 공통 검증인 세트를 공유한다는 아이디어를 말합니다. 작동 방식은 다음과 같습니다.

공유된 분산화

공유 시퀀서의 핵심 아이디어는 각 애플리케이션 체인 또는 L2에 대해 서로 다른 유효성 검사기 세트를 가질 필요가 없다는 것입니다. 그러나 모든 체인에 대해 블록을 주문하는 매우 효율적이고 분산된 검증인 세트를 갖는 것이 가능합니다.

오늘날 거의 모든 시퀀서는 중앙 집중화되어 있으므로 시퀀서는 트랜잭션을 수집하고, 정렬하고, 실행하고 결과를 L1에 게시하는 단일 애플리케이션으로 취급됩니다. 그러나 이러한 작업은 모듈식 구성 요소로 나눌 수 있습니다. 설명을 위해 두 부분으로 나누어 보겠습니다.

정렬 엔진:특정 순서로 거래를 정렬하는 일을 담당합니다. 정렬 엔진이 이 순서를 결정하면 이를 따라야 합니다. 이는 L1에서 이 주문을 커밋하고 L1 검증자가 트랜잭션이 필요한 순서대로 실행되는지 확인하도록 함으로써 구현됩니다.

롤업 엔진:롤업 엔진에는 기본적으로 롤업이 수행하는 모든 작업이 포함됩니다. 즉, 사용자로부터 트랜잭션을 수집하고, 트랜잭션을 실행하고, 증명을 생성하고 L1에서 상태를 업데이트합니다. 이상적으로는 더 많은 구성 요소로 나눌 수 있지만 이 기사에서는 그렇게 하지 않겠습니다. 여기서 정렬 엔진은 공유 정렬기이고 Rollup 엔진은 기본적으로 모두 Rollup 논리입니다.

따라서 트랜잭션의 라이프사이클은 다음과 같습니다.

공유 시퀀서는 기본적으로 롤업의 트랜잭션을 정렬하고 L1에서 커밋합니다. 공유 분류기는 공유 분류기 세트를 분산화합니다. 즉, 이 분류기 세트에 연결된 모든 롤업이 분산화됨을 의미합니다.

구성 가능성

구성 가능성의 주요 문제는 다른 애플리케이션 체인에서 트랜잭션이 완료되는 시기를 알고 이에 따라 체인에서 조치를 취하는 것입니다. 그러나 공유 분류기를 사용하면 구성 가능한 롤업이 서로 블록을 공유할 수 있습니다. 따라서 롤업 B에서 트랜잭션 롤백이 발생하면 전체 블록이 롤백되고 이로 인해 롤업 A의 트랜잭션도 롤백됩니다.

이제 이것은 확실히 실제보다 더 쉽게 들립니다. 이를 위해서는 롤업 간의 통신이 효율적이고 확장 가능해야 합니다. 공유 시퀀서는 롤업의 통신 방법, 크로스체인 메시지의 형태, 롤업 업그레이드 처리 방법 등에 대한 적절한 표준을 개발해야 합니다. 이러한 문제는 해결 가능하지만 구현하기는 쉽지 않습니다.

개발자 경험

공유 시퀀서는 분산 측면을 추상화하여 체인 간 메시징을 더 쉽게 만들지만, 공유 시퀀서와 호환되기 위해 각 체인이 따라야 하는 몇 가지 표준이 여전히 있습니다. 예를 들어 모든 롤업 트랜잭션은 시퀀서가 이해할 수 있는 공통 형식으로 변환되어야 합니다. 마찬가지로 관련 트랜잭션을 얻으려면 시퀀서의 블록을 필터링해야 합니다. 이 문제를 해결하려면,공유 분류기는 상용구 코드를 추상화하고 비즈니스 로직 부분만 애플리케이션 체인 개발자에게 공개하는 롤업 프레임워크 또는 SDK를 출시할 것이라고 생각합니다.

다음은 공유 시퀀서를 사용할 때 애플리케이션 체인의 개략도입니다.

Ethereum의 다중 체인이 Polkadot의 디자인 아키텍처에서 배울 수 있습니까?

Polkadot은 Ethereum 이전에 다중 체인 미래를 연구하고 있었습니다. 실제로 그들은 이 작업을 5년 넘게 진행해 왔습니다. Polkadot에 익숙하신 분이라면 위의 디자인이 기본적으로 Polkadot이 이미 수행하고 있는 많은 작업을 재창조했다는 사실을 눈치채셨을 것입니다.

릴레이 체인(공유 분산화)

릴레이 체인은 기본적으로 위 시퀀스 다이어그램의 정렬 엔진 + L1입니다. 릴레이 체인의 기능은 다음과 같습니다.

모든 파라체인(Rollup)의 트랜잭션을 정렬하여 트랜잭션이 올바르게 실행되었는지 확인합니다(영지식 검증을 사용하지 않고 Rollup의 실행 코드를 다시 실행하여 상태 차이를 확인합니다).

아시다시피 릴레이 체인은 기본적으로 위에서 논의한 공유 시퀀서입니다. 차이점은 릴레이 체인에도 검증 실행이 필요하다는 점인데, 이를 이더리움에 맡깁니다.

XCM과 XCMP

이전 섹션에서 각 체인이 다른 체인과 상호 운용되는 자체 방식을 구축하면 곧 모든 체인에서 서로 다른 표준과 형식을 보게 될 것이라고 언급했습니다. 각 체인과 상호 작용하는 이러한 모든 형식을 추적해야 합니다. 또한 체인이 업그레이드되면 어떻게 되는지 등의 질문에 답해야 합니다. 그러나 이러한 문제는 모든 체인이 따라야 하는 표준을 도입함으로써 해결될 수 있습니다.

짐작하셨겠지만 Polkadot은 이미 이 작업을 수행하고 있습니다. XCM은 메시지 형식이고 XCMP는 모든 하위 체인이 서로 통신하는 데 사용할 수 있는 메시지 프로토콜입니다.

기질과 적운

Substrate는 블록체인 구축을 위해 Parity가 개발한 프레임워크입니다. Polkadot의 모든 파라체인은 Substrate를 사용하지만 Substrate는 실제로 체인에 구애받지 않는 방식으로 구축됩니다. 프레임워크는 블록체인의 모든 일반적인 측면을 추상화하고 애플리케이션 논리에 중점을 둡니다. 아시다시피 Madara는 Polkadot, Polygon Avail 및 기타 여러 프로젝트와 마찬가지로 Substrate를 기반으로 제작되었습니다. 또한 Cumulus는 체인을 Polkadot에 연결할 수 있는 Substrate 위에 있는 미들웨어입니다.

따라서 이전 비유를 계속하면 Substrate와 Cumulus는 애플리케이션 체인을 구축하고 이를 공유 시퀀서에 연결할 수 있는 Rollup 프레임워크의 대체 솔루션으로 간주될 수 있습니다.

공유 시퀀서 → 릴레이 체인

구성성 → XCM 및 XCMP

롤업 프레임워크/스택 → Substrate 및 Cumulus

위의 내용은 기본적으로 Polkadot의 복사본입니다. 단, Polkadot과 Parity에는 Substrate와 Polkadot을 지속적으로 개선하여 더 많은 기능을 추가하고 확장성을 향상시키는 경험 많고 자금이 풍부한 팀이 있습니다. 이 기술은 수년간 현장 테스트를 거쳤으며 다양한 개발 도구와 함께 제공됩니다.

Ethereum에서 Polkadot을 정착시키시나요?

Polkadot은 Ethereum 이전에 다중 체인 미래를 구축하기 시작했지만 오늘날 Ethereum이 가장 분산된 블록체인이며 대부분의 응용 프로그램과 유동성이 있는 곳이라는 점을 부인할 수 없습니다. 하지만 모든 Polkadot 기술을 이더리움 생태계로 가져올 수 있는 방법이 있다면 어떨까요?

사실 우리는 이미 이에 대한 작업을 시작했으며 Madara가 그 예입니다. Madara는 Substrate 프레임워크를 사용하여 누구나 Ethereum에서 자신만의 ZK 기반 L2/L3 솔루션을 구축할 수 있도록 합니다. 다음으로 필요한 것은 공유 시퀀서 형태의 Polkadot 릴레이 체인입니다. Polkadot 릴레이 체인을 재사용할 수 있지만 유효성 검사 부분을 제거하면 L1의 zk 증명을 통해 거래 순서가 확인되고 거래 순서가 L1에 제출되므로 Tendermint/HotStuff를 지원하도록 노드와 합의 알고리즘을 최적화할 수 있습니다. 앞서 언급한 공유 분류기를 얻으세요.

분명히 이것은 말처럼 쉽지 않습니다. 그러나 나는 이 경로가 시퀀서, 표준 및 프레임워크를 처음부터 다시 구축하는 것보다 더 실용적이라고 생각합니다. Polkadot은 Ethereum을 위해 빌릴 수 있는 체인에 구애받지 않는 방식으로 많은 문제를 해결했습니다. 부산물로 우리는 또한 다음을 얻습니다:

● Substrate에 대한 세상을 지속적으로 구축하고 교육하는 활발한 개발자 커뮤니티입니다.

● 활발한 개발 도구 세트와 강력한 커뮤니티.

● 많은 활성 파라체인에는 원할 경우 Ethereum에 정착할 수 있는 옵션도 있습니다(최근에는 Astar가 Polygon CDK를 사용하여 동일한 작업을 수행하는 것을 보았습니다).

결론적으로

이 기사를 작성하는 나의 주요 목표는 Starknet과 Ethereum의 더 넓은 생태계 내에서 토론을 촉발하는 것입니다. 나는 공유 주문 모델이 스타크넷의 분산화와 그 위에 구축되는 모든 애플리케이션 체인의 분산화에 중요한 역할을 할 것이라고 생각합니다. AppChain 주장과 ZK의 확장성에 대한 확신이 있는 한, 공유 주문 모델에 대한 철저한 분석은 불가피합니다. 또한 Madara가 생산을 향해 나아가고 Starknet이 분산화 작업을 시작함에 따라 이제는 이 문제를 해결해야 할 때라고 생각합니다. 따라서 나는 이 게시물을 읽는 모든 사람에게 이 주제에 대한 피드백/제안을 요청합니다. 당신의 생각을 읽기를 기대합니다.