맵 프로토콜: 최종 목표가 상호운용성 계층인 이유는 무엇인가요?

출처: Chain View

최근 BTC 레이어2가 등장하고, 불완전한 통계로 인해 수백 개의 프로젝트가 줄을 잇고 있으며, 전체 확장 생태계는 번영하고 혼란스러운 장면을 연출하고 있습니다.

이 때문에 BTC 레이어2 트랙에 새로 진입한 체인은 적절한 카드 위치를 찾아야 합니다.

비트코인 생태계의 @맵프로토콜올은 잘 알려져 있지만, 그 최종 목표는 레이어2가 아니라 BTC의 상호운용성 레이어일 수 있습니다. 왜일까요?

제 생각에는 BTC 레이어2 생태계에는 명확한 표준과 사양이 없고, BTC 레이어2 생태계가 더 투명해질 수 있는 방법이 없기 때문이죠. 성숙한 EVM 호환 체인을 BTC 레이어2로 취급할 수 있고, BTC 자산을 안전하게 교차 체인화할 수 있는 독립적인 사이드체인을 BTC 레이어2로 취급할 수 있으며, UTXO와 같은 계정 모델을 가진 새로운 성능 체인을 BTC 레이어2로 취급할 수 있는 등 BTC 레이어2 생태계에 대한 명확한 "표준" 또는 "사양"은 존재하지 않습니다.

이론적으로 체인이 BTC 생태계 관련 자산에 접근할 수 있고, BTC 자산의 제2의 붐을 촉진할 수 있다면 확장 체인은 BTC 레이어2로 분류할 수 있습니다. "레이어2"의 정의와 경계에 대한 무례함의 극치처럼 들리지만, 얼마 전 이더리움 레이어2 스크롤 전쟁에 직면한 비탈릭도 레이어2 개념을 포기하자고 제안하지 않았나요?

어느 정도까지, BTC 레이어2는 현재 혼란스러운 장애 (엔트로피 엔트로피) 상태는 어떤 개별 형태의 주관적인 의지에 의해 제어되지 않으며, 점차적으로 명확하게 수렴하기 위해 오랜 기간의 합의 마찰, 기술적 교살, 시장 파열, 승자와 패자를 거쳐야 합니다.

이전에는 비트VM 챌린지 메커니즘에서 @BSquaredNetwork의 특수성을 분석하는 기사를 썼고, 통화 트윗에서 @ParticleNtwrk의 공동 @BitmapTech의 BTC Connect, MAP 프로토콜에 대한 추상적 인 디자인을 오랫동안 언급했습니다. 분석 할 수 있습니다.

정직하게 말해서 처음에는 요점을 제대로 파악하지 못했습니다.

정직하게 말해서 처음에는 이해가 되지 않았습니다. 원래 풀체인 상호운용성을 위해 레이어제로를 목표로 했던 체인이 갑자기 비트코인 레이어2 생태계에 올인한다고 광고했기 때문에, 사람들은 항상 '내러티브'에 자신을 맡기는 듯한 느낌을 받았습니다. 결국, 내러티브를 통해 전체 체인을 할 수 있다는 것은 분명한데, 비트코인 레이어2에 위치한다면 스스로 제한하는 것과 같지 않습니까?

이를 염두에 두고 먼저 MAP 프로토콜의 기술적 논리적 프레임워크를 간략히 분석해 보겠습니다.

MAP은 타사 센터와의 피어 투 피어 상호 운용성에 초점을 맞춘 ZK의 라이트 클라이언트를 기반으로 하는 피어 투 피어 인프라로 포지셔닝되어 있습니다. 어떻게 하나요? MAP의 프로그램은 실제로 체인에서 BOB 체인에 해당하는 MAP 릴레이 체인을 구축하는 것이며, 릴레이 체인은 컨트랙트 동형 다른 체인 서명 알고리즘에서 미리 컴파일되어 체인 간 통신 및 마찰 없는 자산 전송 기능을 얻을 수 있습니다.

BTC를 예로 들면, MAP는 먼저 BTC 체인에 ZK 라이트 클라이언트를 배포하고, 라이트 클라이언트는 BTC 메인 네트워크에서 일부 작업을 수행하기 위해 전체 노드의 기록 데이터를 다운로드할 필요가 없으며, 예를 들어 거래와 관련된 블록 헤더 및 머클 증명을 확인하여 2계층 체인에서 코인 인출 요청이 수행될 때 메인 네트워크의 라이트 클라이언트는 특정 거래 부분과 관련된 데이터만 확인하면 안전하게 작업을 완료할 수 있음을 실현할 수 있습니다. 안전하게 작업을 완료할 수 있습니다.

이 기술은 비트코인 백서에서 처음 정의된 간편 결제 검증(SPV) 기술에서 파생된 것입니다.

BTC 메인넷을 자산 결제 레이어로 간주할 때 라이트 노드 클라이언트 방식을 채택하면 체인 전반의 자산 전송 보안을 크게 개선하는 동시에 전체 노드 검증에 따른 리소스 손실과 비용을 피할 수 있습니다. ZK 기술 지원을 사용하는 이유는 레이어2 사이드 체인 운영과 메인 네트워크 검증 합의가 일관성을 유지할 수 있도록 하기 위해서입니다.

(명확히 해야 할 점은 라이트 클라이언트는 결제 유형만 확인할 수 있고 레이어2 체인의 상태 유효성을 확인할 수 없으며, 즉 메인 네트워크는 레이어2에서 제출한 데이터의 일부를 기반으로 자산 전송을 위한 UTXO 잠금 해제 조건의 잠금 해제 여부를 확인할 수 있으며 더 복잡한 상태의 레이어2 체인에서는 확인할 수 없습니다)

고려해야 합니다. ZK 라이트 클라이언트 + 릴레이 체인 접근 방식은 실제로 자산의 안전한 크로스 체인 및 동일 체인 마모 없는 변환을 달성할 수 있습니다. 릴레이 체인은 전체 체인 환경에 적합한 스마트 컨트랙트를 배포하고(스마트 컨트랙트가 없는 BTC는 안전한 자산 이전을 위해 라이트 클라이언트를 사용합니다), 일련의 POS 기반 상호 작용 유효성 검증 메커니즘과 함께 크로스 체인 통신을 위한 일련의 표준을 따릅니다. 이 모든 과정을 통해 체인 전반의 상호운용성 솔루션을 구성합니다.

MAP 프로토콜은 전체 체인 상호운용성을 위한 유전자를 가지고 있기 때문에, BTC 레이어2로 포지셔닝될 경우 발전 경로가 달라집니다.

1) MAP은 BTC 메인 네트워크의 특성에 집중하여 레이어2 기능을 강화함으로써 BTC의 주요 자산 외에도 많은 비문 자산과 같은 BTC의 자산을 안전하게 레이어2로 교차 체인화할 수 있도록 할 것입니다.

이유

BTC 자산의 유통에 대한 강력한 합의로 인해, 어떤 레이어2 확장 프로그램도 비문 자산이 다르면 BTC 보유자의 합의를 깨뜨리기 어렵습니다. BTC 레이어2는 이러한 BTC 파생 자산을 보다 저비용, 저손실로 관리 및 유통하여 BTC 홈 네트워크의 가치를 확장하는 레이어2의 목표를 달성할 수 있습니다.

. 이 목표를 달성하기 위해서는 단순히 BTC 자산을 레이어2 체인에 랩핑하는 것만큼 간단하지 않으며, 여기에는 인덱서 인덱서의 장부 일관성 관리, 다양한 BTC 파생 비문 자산의 호환성 및 유동성 관리 등이 포함됩니다. 물론 BTC의 고유 특성에 부합하는 BTC 파생 자산의 특성을 중심으로 보다 확장된 성능을 개발하는 것이 관건입니다.

2) MAP은 다른 BTC 레이어2의 상호운용성 레이어(레이어0)가 될 것이며, BTC 레이어2가 다수의 성숙한 EVM 체인뿐만 아니라 다수의 비 EVM 성능 체인에 의해 액세스될 때, 이러한 체인은 어떤 방식으로든 BTC 메인 체인에 연결될 수 있지만 핵심 문제는 정확히 상호운용성이 아니라고 상상해 보십시오. 하지만 핵심 문제는 상호 운용성이 아닐까요? 분명히 BTC 메인넷과 충분히 이질적이고 다른 체인 전반의 환경과 호환되는 체인 내 체인이 핵심이 될 것입니다.

MAP은 레이어2 체인의 최고 경영자 자리를 놓고 경쟁하지 않고, 다른 레이어2 체인이 서로 어떻게 경쟁하는지 지켜본 다음, 시장이 분열될 때 자체적인 체인 전반의 상호운용성 특성을 기반으로 유동성을 통합하고 관리할 수 있습니다.

이것은 제가 보기에 완벽한 움직임인 것 같습니다.

물론 BTC 레이어2 경쟁의 야만적인 시기에 모두가 C 포지션을 차지하기 위해 머리를 쥐어짜고 있고, BTC 메인 체인이 객관적으로 결함이 있다는 사실을 무시하고 세컨드 레이어 체인의 핵심 가치를 이해하지 못하는 프로그램들이 시장에서 활약하고 있기 때문에 이러한 맥락에서 안정화되고 자신만의 생태적 틈새를 찾을 수 있는 BTC 레이어2가 궁극적인 승리의 열쇠가 될 수 있습니다.