기술 가이드: Supra 블록체인 기술 스택에 대한 완전한 설명

星球君的朋友们

Odaily资深作者

2024-12-19 14:11 (UTC+8)

이 기사는 약 13498자로, 전체를 읽는 데 약 20분이 소요됩니다

초고성능의 만능 통합 블록체인을 만드는 것을 목표로 합니다.

AI 요약

초고성능의 만능 통합 블록체인을 만드는 것을 목표로 합니다.

요약

Supra는 가격 오라클, 온체인 난수, 크로스체인 통신 및 자동화 기능을 포함하여 MultiVM 스마트 계약 지원 및 기본 서비스와 완전히 수직적으로 통합된 강력한 고성능 아키텍처에 수년간의 혁신을 통합합니다.

이를 바탕으로 이 기사에서는 Supra 블록체인의 엔드 투 엔드 트랜잭션 프로세스를 자세히 설명하고 검열 위험과 최대 추출 가능 가치(MEV) 공격의 위협을 효과적으로 완화하는 방법을 보여줍니다.

Supra 네트워크는 공유 보안 플랫폼을 기반으로 광범위한 서비스와 기능을 제공합니다. 여기에는 DORA(Distributed Oracle Protocol), DVRF(Distributed Verifying Random Functions), 제로 블록 대기 시간 자동화 네트워크, AppChain에서 영감을 받은 컨테이너 아키텍처, 다중 VM 지원, 병렬 트랜잭션 처리를 통한 최적화 등 혁신적인 기술이 포함됩니다. 또한 Supra의 크로스체인 설계인 HyperLoop 및 HyperNova는 Supra를 스마트 계약 플랫폼 로직을 통해 다중 체인 상호 연결을 실현하는 세계 최초의 "IntraLayer"로 만듭니다.

1. 블록체인 서비스의 기본적이고 완전한 수직 통합

Supra는 획기적인 연구와 뛰어난 엔지니어링 역량을 통해 블록체인 기술의 변혁을 촉진하는 데 전념하고 있습니다. 목표는 다양한 블록체인 관련 서비스를 완전히 통합하여 개인 사용자, 기관 고객 및 개발자에게 통합 솔루션을 제공하는 효율적인 Layer 1 블록체인을 구축하는 것입니다. 원활한 사용자 경험.

이 글에서는 Supra 기술이 고대 그리스 철학자 아리스토텔레스의 유명한 명언인 "전체는 부분의 합보다 크다"를 어떻게 해석하는지 보여드리겠습니다. 완전한 수직적 통합이라는 개념을 고수하면서 Supra는 포괄적인 블록체인 기능 세트를 제공합니다. 풍부한 생태계 개발과 다양한 애플리케이션 시나리오를 지원하는 서비스입니다.

핵심 기능 개요

dApp용 Supra 블록체인에서 제공하는 기본 서비스(그림 1 참조)는 다음과 같은 핵심 기능을 다룹니다.

레이어 1 블록체인

기본 토큰, 프로그래밍 가능한 대체 가능 및 대체 불가능 토큰, 표준화된 크로스체인 토큰을 포함한 다양한 자산 유형을 지원합니다.

스마트 계약 실행 환경

DeFi 프로토콜, 블록체인 게임, 복권, 공급망 추적 등과 같은 다양한 공개 블록체인 애플리케이션에 적합한 다양한 Turing-complete 스마트 계약 플랫폼을 체인에 제공합니다.

오프체인 데이터 서비스

암호화폐 가격 오라클, 환율, 주가 지수, 날씨 데이터 등 수요 기반(풀) 및 스트리밍(푸시) 데이터 서비스를 제공합니다. 이러한 데이터는 Supra 블록체인을 제공할 뿐만 아니라 다른 블록체인 네트워크도 지원하는 Supra의 DORA(Distributed Oracle Protocol)를 통해 전송됩니다.

그림 1 완전한 수직적 통합

온체인 난수 서비스 푸시 및 풀 <br/>난수 서비스 생성 및 배포를 위해 웹 2.0 및 웹 3.0 사용자를 위한 스트리밍 및 온디맨드 형식으로 분산 검증 가능한 난수 함수(dVRF)를 제공합니다.
자동화 네트워크는 <br/>DORA를 통해 제공되는 특정 시간 노드, 온체인 이벤트 또는 오프체인 이벤트를 기반으로 트랜잭션 실행을 예약하는 데 사용됩니다. 예를 들어, 고객은 "2025년 6월 1일 정확히 12:00 EST에 ETH 가격이 $4,000를 초과하면 내 DOGE를 판매하세요."라고 요청할 수 있습니다.
애플리케이션별 체인(AppChain)
Supra의 컨테이너는 상당히 낮은 배포 비용으로 AppChain의 유연성과 자율성을 제공하고 Supra 네트워크의 고성능, 공유 보안 및 통합 유동성의 이점을 누릴 수 있습니다.

2. IntraLayer: Supra와 다른 블록체인 연결

Supra는 일련의 기본 서비스를 제공하지만 멀티체인 생태계의 현실과 가치를 깊이 이해하고 있습니다. 상호 운용성을 향상시키기 위해 우리는 스타 토폴로지를 설계했습니다(그림 2 참조). 이 구조에서 Supra의 L1 블록체인과 해당 통합 서비스는 IntraLayer 네트워크의 핵심 역할을 하며 상호 운용성을 통해 문제를 해결합니다. 솔루션 HyperLoop 및 HyperNova는 다른 L1 및 L2 블록체인을 연결합니다. .

독립적인 MultiVM 스마트 계약 플랫폼인 Supra는 자체 서비스를 제공할 뿐만 아니라 멀티체인 생태계에서 중요한 역할을 하기 위해 최선을 다하고 있습니다. 이 역할은 네트워크 간 또는 "네트워크 내"의 가치 교환에 반영되어 기본 스마트 계약, 자동화 기능 및 오라클 서비스를 통해 안전하고 효율적인 통신을 가능하게 합니다.

하이퍼루프

HyperLoop는 전통적인 다중 서명 크로스체인 프로토콜을 기반으로 하며, 게임 이론에 의해 엄격하게 분석되고 검증된 보안 솔루션으로, 크로스체인 거래의 신뢰성을 보장하는 업계 최초의 혁신적인 설계입니다.

하이퍼노바

무신뢰 상호운용성 솔루션인 HyperNova는 크로스체인 통신에 높은 보안을 제공하여 멀티체인 생태계에서 정보 및 가치 교환을 위한 견고한 기반을 마련합니다.

HyperLoop 및 HyperNova를 통해 Supra는 광범위한 체인 간 상호 연결을 달성하고 사용자와 개발자에게 강력한 도구를 제공하며 다중 체인 생태계의 심층 통합 및 개발을 촉진합니다.

그림 2 Supra의 IntraLayer

연결된 체인의 보안은 전통적인 크로스체인이나 릴레이 노드의 보안 가정에 의존하지 않습니다. 여기에서는 HyperLoop와 HyperNova가 가장 적합한 특정 시나리오를 간략하게 설명합니다.

하이퍼루프
우리는 HyperLoop 크로스체인 솔루션이 최종성을 달성하는 데 필요한 사기 방지 문제 기간을 없애기 때문에 Optimistic Rollup을 Supra에 연결하는 데 특히 적합하다는 것을 발견했습니다.
하이퍼노바
연결된 체인의 보안을 유지하기 위해 Supra 대화형 체인의 합의를 다시 계산하여 L1-L1 보안을 유지하므로 지분 증명(PoS) L1 블록체인을 Supra에 연결하는 데 적합합니다. Supra의 L1 블록체인은 안전하고 효율적인 크로스체인 통신을 촉진하도록 특별히 설계되었습니다.

우리의 계획에는 HyperNova를 사용하여 Bitcoin을 Supra에 교차 연결하는 동시에 HyperLoop를 통한 역방향 연결을 활성화하는 것이 포함됩니다. 또한, 우리는 체인 간 상호 운용성을 더욱 향상시키기 위해 이 환경에서 원자 교환을 구현하는 방법을 모색하고 있습니다.

Supra IntraLayer 기술 스택이 제공하는 핵심 기능 중 일부는 다음과 같습니다.

DeFi 인트라레이어
"플랫폼 위의 플랫폼"으로서 Supra는 다양한 주류 DeFi 프로토콜(예: AMM)을 캡슐화합니다. dApp 개발자는 여러 블록체인의 자산과 정보에 쉽게 액세스하여 크로스체인 개발 프로세스를 단순화할 수 있습니다.
크로스체인 자동화 서비스
우리는 사용자가 여러 블록체인의 이벤트와 데이터를 기반으로 자동화된 작업을 설정할 수 있도록 하여 사용자 경험과 운영 효율성을 크게 향상시킵니다.

우리는 여러 기본 서비스를 고성능 L1 블록체인에 완전히 수직적으로 통합하는 것이 세계 최초의 크로스체인 IntraLayer를 구축하려는 우리의 비전과 매우 일치한다고 굳게 믿습니다. 다른 블록체인에서 우리 서비스에 대한 수요가 계속 증가함에 따라 토큰 및 온체인 자산을 포함한 Supra 네트워크의 유틸리티는 가치의 자연스러운 변동을 생성하여 사용자와 고객이 우리 인프라를 채택하도록 더욱 장려할 것입니다.

동시에 IntraLayer 아키텍처가 다양한 생태계에서 널리 사용됨에 따라 점점 더 많은 개발자가 IntraLayer의 기본 서비스와 뛰어난 성능에 매력을 느끼고 Supra 블록체인에서 직접 애플리케이션을 개발하고 구축하도록 선택할 것입니다. 이는 내부적으로 개발된 프로토콜과 타사 프로토콜을 포함하여 DeFi 계층을 향상시킬 뿐만 아니라 네트워크의 전반적인 채택과 견인력을 촉진할 것입니다.

우리는 뛰어난 성능과 원스톱, 다양한 서비스를 통해 Supra가 개발자 커뮤니티에 Web 3.0 기술의 차세대 대중화 물결을 가져오고 전체 생태계의 빠른 발전을 도울 것이라고 믿습니다.

3. Supra의 핵심 - "Tribe and Clan" 노드 모델

Supra의 기본 철학은 완전히 수직적으로 통합되어 사실상 모든 블록체인 관련 서비스를 단일 플랫폼에서 제공하는 것입니다. 이 솔루션은 사용자와 개발자가 통합되고 원활한 경험을 보장합니다.

완전한 수직 통합과 모듈형 레이어 2 비교

Supra는 기존의 모듈식 L2 솔루션과 다른 수직 통합 아키텍처를 채택합니다.

L2에서는 핵심 기능(합의, 실행, 데이터 가용성 등)이 독립적인 네트워크에 분산되어 있습니다. 이러한 설계를 "모듈성 이점"이라고 부르지만 다음과 같은 많은 문제가 발생합니다.

대기 시간 증가: 네트워크 간 통신으로 인해 시간 지연이 발생합니다.
경제적 보안은 분산되어 있습니다. 서로 다른 네트워크에는 자체 토큰이 있으며 보안을 공유할 수 없습니다.
높은 복잡성: 전체 아키텍처를 유지 관리하고 조정하기가 더 어렵습니다.

대조적으로, Supra의 완전히 수직적으로 통합된 디자인은 모든 구성 요소를 단일 블록체인으로 통합합니다.

경제적 보안과 통일된 토큰 경제를 공유합니다.
통신 지연을 대폭 줄이고 시스템 성능을 향상합니다.
통합된 인센티브 메커니즘으로 네트워크 보안이 향상됩니다.
전체 운영 비용이 절감됩니다.

비잔틴 내결함성 혁신

분산 시스템 연구에 따르면 비동기식 또는 부분 동기식 네트워크에서 기존 BFT(비잔틴 결함 허용) 프로토콜은 노드의 최대 1/3만 악성 노드로 허용할 수 있는 것으로 나타났습니다. 그러나 Supra의 혁신적인 혁신은 이러한 내성을 절반으로 늘려 전례 없는 안전성과 효율성을 가능하게 합니다.

정렬 서비스 및 무결성 체인

Supra L1 블록체인의 핵심은 주문 서비스입니다. 합의 프로토콜은 거래 주문을 담당하며 거래 데이터의 보급은 주문 서비스와 분리되어 있습니다. 그러므로:

블록에는 특정 거래 데이터가 아닌 거래 배치의 메타데이터(예: 다이제스트 및 데이터 가용성 증명)만 포함됩니다.
이는 Supra 블록체인의 블록을 매우 작게 만들어 운영 효율성을 크게 향상시킵니다.

주문 서비스는 다른 모든 서비스의 핵심 기반이므로 Supra 블록체인을 "무결성 체인"이라고 부릅니다.

더 많은 비잔틴 노드를 허용하는 것이 왜 중요한가요?

더 많은 비잔틴 노드를 허용하면 직접적인 이점은 다음과 같습니다.

소규모 위원회: 예를 들어 50개의 악성 노드를 허용하려면 기존 방법에는 151명의 구성원이 필요한 반면 Supra에는 101명의 구성원만 필요합니다.
비용 절감: 합의 노드 수를 줄이면 보상해야 할 노드 수가 줄어들어 사용자 수수료가 낮아집니다.
실행 속도 향상: 합의 노드 수가 적어 강력한 보안을 유지하면서 프로세스가 더 빨라집니다.

그림 3 부족, 씨족, 가족

부족, 씨족 및 가족

이 코어는 Supra 블록체인에서 여러 서비스의 효율적이고 완전한 수직 통합을 촉진합니다. Supra는 부족, 클랜 또는 가족 수준에서 다양한 알고리즘의 실행을 지원하는 새로운 네트워크 프레임워크를 제안합니다.

그림 3에 표시된 대로:

Tribe는 비잔틴 노드의 최대 1/3을 허용하는 노드 위원회입니다.
클랜은 최대 비잔틴 노드의 절반을 허용하는 노드 위원회입니다.
Family는 적어도 하나의 올바른 노드가 필요한 노드 위원회입니다.

최적의 성능과 강력한 보안을 달성하기 위해 우리 네트워크는 다음과 같이 구성됩니다. 활성 노드는 합의 프로토콜을 실행하고 주문 서비스를 지원하며 비잔틴 노드의 최대 1/3을 허용하는 부족으로 구성됩니다.

우리 디자인의 핵심 포인트는 전체 Supra 부족이 거래 실행에 참여하거나 전체 Supra 상태를 유지할 필요가 없다는 것입니다. 대신, “클랜”이라고 불리는 더 작은 하위 집합이 상태를 관리하고, 트랜잭션을 실행하고, 블록의 사후 상태를 계산하고, 상태 약속에 서명합니다. 따라서 거래 데이터의 전파는 처음에는 클랜 수준에서만 발생하고 이후에는 계속해서 전파됩니다.

이 아키텍처는 다양한 클랜이 독립적인 가상 머신을 사용하여 다양한 상태 샤드를 관리하는 효율적인 상태 샤딩에 매우 적합합니다. 이 디자인은 확장성을 향상시켜 더 많은 클랜(또는 샤드)을 추가하여 처리량을 조정할 수 있게 해줍니다. 따라서 합의 이외의 모든 프로토콜(예: 데이터 전파, 샤딩 실행, 오라클 서비스, 분산 난수 서비스)은 단순 다수의 올바른 노드만 필요한 소규모 위원회(클랜)에서 실행됩니다.

우리는 클랜이 실제로 클랜의 분할을 형성하도록 노드를 클랜으로 무작위로 선택하여 순서가 지정된 클랜과 여러 서비스 클랜을 함께 구성합니다. 합의 또는 글로벌 주문은 부족에서 실행되는 반면, 검증 가능한 다양한 계산 서비스는 클랜에서 수행됩니다. 노드를 무작위로 선택하면 클랜 수준에서 작업을 수행할 수 있으며 시스템에 확률 요소가 도입됩니다. 예를 들어 부족이 625개의 노드로 구성되어 있으며 최대 208개의 비잔틴 노드가 있다고 가정합니다. 부족이 각각 125개의 노드를 갖는 5개의 클랜으로 나누어진다면, 한 클랜의 노드 중 절반 이상(즉, 62개)이 비잔틴 노드일 확률은 약 35 × 10 ⁻⁶입니다. 즉, 부족의 비잔틴 노드가 33%일 때 "나쁜 클랜"이 존재할 확률은 백만분의 35에 불과합니다. 실제로 이러한 확률은 매우 낮습니다. 우리는 기간과 기간을 논의할 때 이러한 확률을 더 분석하고 실제로는 거의 무시할 수 있음을 보여줄 것입니다.

4. 거래과정

Supra 체인의 거래 프로세스는 대략 다음과 같으며, 구체적인 단계는 다음 장에서 자세히 설명합니다.

그림 4는 Supra 블록체인의 엔드 투 엔드 트랜잭션 프로세스를 보여줍니다.

사용자는 Supra의 Starkey 지갑[3] 또는 dApp을 통해 거래를 제출합니다. 지갑은 트랜잭션 ttt가 전송되는 게이트웨이 RPC 노드에 연결됩니다.
게이트웨이 RPC 노드는 기본 검증 및 분류를 기반으로 특정 배치 제안자의 기본 버킷에 트랜잭션 ttt를 보내고 다른 배치 제안자의 보조 버킷에 트랜잭션을 보냅니다.
배치 제안자는 기본 버킷의 트랜잭션을 압축하고 보조 버킷의 시간 초과된 트랜잭션을 배치에 추가합니다. 자세한 내용은 섹션 5를 참조하세요.
배치는 xRBC 프로토콜을 통해 해당 실행 클랜 노드로 전파되며, 배치가 블록에 포함되기 전에 DAQC(Data Availability Quorum Certificate)가 형성되어야 합니다. 이러한 인증서는 부족 전체에 전파되고 배치는 게이트웨이 RPC 노드에 전파됩니다.
부족 노드는 Supra의 Moonshot 합의 프로토콜을 실행합니다. 블록 제안자는 이러한 DAQC 및 관련 배치 메타데이터를 패키징하여 블록을 구축합니다.
합의 프로토콜은 블록을 주문하므로 일괄적으로 트랜잭션을 간접적으로 주문합니다. 블록이 확정되면 합의 프로토콜을 실행하는 모든 부족 노드와 모든 클랜 노드에서 볼 수 있습니다. 최종화된 블록은 게이트웨이 RPC 노드에도 전파됩니다.
클랜 노드는 최종 블록에서 해당 트랜잭션 배치를 실행하고 현재 블록체인의 끝에서 블록체인 상태를 업데이트합니다. 그 후, 사후 상태를 계산하고, Merkleization 작업을 수행하고, 새로운 Merkle 루트를 계산합니다. 서로 다른 클랜은 서로 다른 배치를 병렬로 실행한다는 점에 유의하세요. 클랜 노드는 이 Merkle 루트에 서명하고 이를 게이트웨이 RPC 노드뿐만 아니라 전체 클랜에 전파합니다.
게이트웨이 RPC 노드는 블록을 실행하고, 사후 상태와 해당 Merkle 루트를 계산하고, 수신된 서명된 Merkle 루트와 일치하는지 확인하고, 트랜잭션이 완료되면 지갑에 알립니다.

최종 확인 단계

우리의 작업 흐름에서 거래는 다음과 같은 세 가지 최종 단계를 거치며 각 단계는 블록체인의 거래 상태에 대해 더 강력한 보장을 제공합니다.

사전 확인 단계
트랜잭션 ttt를 포함하는 배치 bbb가 데이터 가용성 쿼럼 인증서(DAQC)를 획득하면 트랜잭션 ttt가 블록체인에 포함된다는 것이 보장됩니다. 이 단계에서는 거래 포함이 보장되지만 정확한 위치와 실행 결과는 아직 결정되지 않았습니다.
정렬 최종성
합의 프로토콜이 배치 bbb를 포함하는 블록의 최종 확인을 완료하면 블록체인에서 트랜잭션 ttt의 위치가 고정되고 변경 불가능하게 되어 다른 트랜잭션과 관련된 실행 순서를 결정합니다.
실행 최종성
이것이 마지막 단계의 끝입니다. 클랜 노드는 일괄 bbb를 실행하고, 트랜잭션 ttt의 실행 결과로 블록체인 상태를 업데이트하고, 새로운 상태의 Merkleized 버전을 생성하고, 생성된 Merkle 루트에 서명하고 브로드캐스트하여 상태 약속을 형성합니다. 이 단계가 완료되면 거래 실행 결과는 최종적이며 되돌릴 수 없습니다.

Supra L1은 빠른 최종성 시간을 지원합니다. 실험에서 이러한 다양한 최종 단계에 대한 관찰 시간은 섹션 7에 보고되어 있습니다.

다음 장에서는 위의 거래 과정에서 중요한 단계를 자세히 설명합니다.

그림 5 메모리 풀이 없는 버킷팅 방식

5. 메모리 풀이 없는 버킷팅 솔루션

먼저 Ethereum과 Solana의 기존 mempool 프로토콜에 대해 논의한 다음 Supra가 이를 어떻게 개선하는지 보여줍니다.

이더리움 메모리 풀 솔루션

전통적인 Ethereum 메모리 풀 프로토콜 프로세스는 다음과 같습니다.

클라이언트(지갑)는 트랜잭션을 RPC 노드로 보내고, RPC 노드는 Gossip 프로토콜을 통해 트랜잭션을 브로드캐스팅하여 모든 합의 검증자에게 도달합니다.
검증인이 블록 제안자가 되면 수신된 거래를 패키징하려고 시도합니다.
블록 제안자는 거래를 블록에 포함하지 않음으로써 거래를 검열하려고 시도할 수 있지만 모든 합의 검증인이 이러한 거래를 보유하므로 블록 제안자가 되는 다음 라운드의 검증인은 누락되거나 검열된 거래를 포함하게 됩니다. 따라서 이 프로토콜은 검열에 저항적입니다.

일반적인 블록체인 아키텍처에서 클라이언트(Web3 지갑)는 트랜잭션을 공용 RPC 노드로 보냅니다. 그런 다음 RPC 노드는 지점 간 가십 프로토콜을 통해 전체 RPC 노드 네트워크 및 합의 유효성 검사기 네트워크에 트랜잭션을 전파합니다. 이러한 노드는 클라이언트가 보낸 트랜잭션을 임시로 저장하기 위해 "mempool"이라는 데이터 구조를 유지합니다.

다음으로, 블록 빌더는 멤풀에서 트랜잭션을 가져와서 블록으로 패키징하고 합의 프로토콜을 통해 처리합니다. 블록이 최종성에 도달하면 포함된 모든 거래도 최종적인 것으로 간주됩니다.

비트코인과 이더리움의 멤풀에는 처리되지 않은 트랜잭션의 대규모 백로그가 있기 때문에 평균적으로 트랜잭션은 블록 빌더에 의해 선택되기 전에 더 오랜 시간 동안 멤풀에 유지됩니다. 또한 지점 간 가십 프로토콜은 트랜잭션을 전파할 때 지연을 더욱 증가시킵니다.

Solana 메모리 풀 없는 솔루션

메모리 풀 지연 시간을 줄이기 위해 솔라나는 다음 프로세스를 통해 메모리 풀 없는 프로토콜을 채택합니다.

블록은 블록 제안자가 미리 결정한 고정된 일정에 따라 생성됩니다.
클라이언트(예: 지갑)는 트랜잭션을 RPC 노드로 보냅니다. RPC 노드는 읽기 및 쓰기 액세스 정보와 같은 보조 데이터를 트랜잭션에 첨부하여 블록을 제안하려는 일부 제안자에게 보냅니다. 제안자가 거래를 놓친 경우 다른 제안자는 후속 블록에 해당 거래를 포함시킵니다.

솔라나 네트워크가 완전한 최종성을 달성하려면 32번의 블록 확인이 필요하다는 점을 기억하는 것이 중요합니다. Solana는 엔드 투 엔드 대기 시간을 최적화하도록 설계되었지만 여전히 트랜잭션 중복이 가끔 발생하여 네트워크 중단을 일으킬 수 있습니다. 이더리움의 멤풀(mempool) 프로토콜과 비교했을 때, 솔라나는 의도한 블록 제안자와 직접 통신을 사용하는데, 이는 트랜잭션 전파 지연을 효과적으로 줄이는 접근 방식입니다.

Supra 메모리 풀리스 프로토콜 솔루션

Solana와 마찬가지로 Supra는 멤풀 없는 프로토콜을 사용하지만 기존의 네트워크 전체 가십 프로토콜을 대상 통신으로 대체합니다. 그러나 Supra의 접근 방식은 두 가지 주요 측면에서 다릅니다.

1. 즉각적인 최종성

Solana의 시간 슬롯 기반 시스템과 달리 Supra는 Moonshot이라는 고전적인 BFT(Byzantine Fault Tolerance) PBFT 스타일 합의 프로토콜을 사용합니다(자세한 내용은 아래 참조). Moonshot 프로토콜에서는 솔라나처럼 32번의 블록 확인을 기다릴 필요 없이 블록이 제출 인증서(QC)를 받으면 즉각적인 최종성을 얻을 수 있습니다. 이는 거래의 최종 확인 시간을 크게 단축하고 시스템 성능을 향상시킵니다.

2. 일괄 메타데이터 저장

Supra의 합의 설계에서 블록은 거래 데이터를 직접 포함하지 않지만 거래 배치의 DAQC 및 메타데이터를 저장합니다(자세한 내용은 섹션 6 참조). 멤풀 없는 프로토콜에서 클라이언트 지갑의 트랜잭션은 그림 5와 같이 지정된 배치 제안자가 관리하는 버킷에 저장됩니다.

당사의 버킷팅 솔루션의 기능은 다음과 같습니다.

1) 중복 제거 메커니즘
각 거래에는 해당 거래를 일괄 처리에 포함시키는 일을 담당하는 고유한 마스터 일괄 처리 제안자가 할당됩니다. 이 단일 책임 모델은 자연스럽게 중복 트랜잭션이 블록체인에 패키징되는 것을 방지합니다.

2) 중복성과 검열 저항
트랜잭션이 누락되지 않도록 하기 위해 하위 배치 제안자를 백업으로 도입했습니다. 기본 배치 제안자가 시간 내에 트랜잭션을 포함하지 못하는 경우 보조 배치 제안자는 시간 초과 후 트랜잭션을 배치에 포함합니다.

여러 명의 2차 제안자가 동시에 트랜잭션을 처리하면 중복 패키징이 발생할 수 있지만 Supra 시스템은 첫 번째 트랜잭션 발생을 통해 일관성을 유지합니다.
반복되는 트랜잭션은 온체인 상태에 영향을 주지 않고 유효하지 않은 트랜잭션 시퀀스 번호로 인해 실행 단계에서 자동으로 종료됩니다.

3) 불변의 책임기록
2차 제안자가 해당 트랜잭션을 블록에 성공적으로 포함시키면 1차 제안자가 임무를 수행하지 못했다는 것을 증명하는 불변의 기록이 생성됩니다. 이 기록은 시스템의 공정성과 신뢰성을 보장하기 위해 트랜잭션을 검열하거나 불필요한 지연을 유발하는 배치 제안자를 처벌하기 위한 후속 네트워크 분석에 사용될 수 있습니다.

메모리 풀이 없는 버킷팅 솔루션의 구체적인 프로세스는 다음과 같습니다.

각 배치 제안자는 기본 버킷과 보조 버킷이라는 두 개의 버킷을 유지 관리합니다.
각 트랜잭션 ttt에 대해 시스템은 고유하고 예측할 수 없는 식별자(해시)를 기반으로 이를 특정 일괄 제안자 패밀리에 할당합니다. 이 패밀리에서 하나의 노드는 트랜잭션 ttt에 대한 기본 배치 제안자로 지정되고 나머지 노드는 보조 배치 제안자로 지정됩니다.
RPC 노드가 지갑이나 dApp 프런트 엔드로부터 트랜잭션 ttt를 수신하면 트랜잭션 식별자를 기반으로 해당 배치 제안자 패밀리에 이를 전달합니다. 기본 배치 제안자는 트랜잭션 ttt를 기본 버킷에 저장하고, 보조 배치 제안자는 트랜잭션 ttt를 해당 보조 버킷에 저장합니다.
새로운 배치를 구축할 때 배치 제안자는 기본 버킷에 모든 트랜잭션을 포함해야 합니다. 비잔틴 동작(예: 기본 버킷에서 특정 트랜잭션을 제외하여 검열)을 방지하기 위해 보조 배치 제안자는 백업 메커니즘으로 작동합니다.
배치가 마무리되고 배치 제안자가 관찰하면 제안자는 기본 및 보조 버킷에서 배치에 포함된 트랜잭션을 제거합니다.
또한 각 트랜잭션 ttt에는 구성 가능한 시간 제한이 있습니다. 시간 초과 전에 ttt가 최종 배치에 포함되지 않은 경우 해당 패밀리의 하위 배치 제안자는 다음 배치를 구축할 때 하위 버킷의 ttt를 포함해야 합니다. 이 메커니즘은 거래가 누락되지 않도록 보장하고 시스템의 검열 저항을 높입니다.

그림 6 기존 솔루션과의 개념적 비교

이 2계층 설계는 효율적인 중복 제거와 강력한 검열 저항 사이에서 영리한 균형을 유지합니다. 또한, 2차 배치 제안자가 트랜잭션을 배치에 성공적으로 통합하면 1차 제안자가 임무를 수행하지 못했다는 것을 증명하는 불변의 기록이 생성됩니다. 이 기록은 후속 분석에 사용될 수 있으며, 거래를 검열하거나 불필요한 지연을 초래하는 일괄 제안자에게 처벌을 부과하는 데 사용될 수 있습니다.

6. 메모리 풀리스 아키텍처: 트랜잭션 데이터 배포 및 트랜잭션 정렬의 효율적인 분리 달성

다음으로 Supra가 부족 클랜 아키텍처를 통해 거래 데이터 전파와 거래 순서를 효율적으로 분리하는 방법을 소개합니다.

최근 몇 년 동안 일부 프로토콜(예: Narwhal/Tusk [11] 및 Bullshark [20])은 트랜잭션 데이터 전송의 중요성을 인식하고 트랜잭션 주문에서 데이터 전송을 분리하기 위해 새로운 설계 패러다임을 채택했습니다. 이 디자인은 병렬로 실행되는 두 개의 하위 프로토콜을 통해 각각 데이터 전송 및 정렬을 구현합니다.

주문 요구 사항이 없으면 데이터 전송은 분산 시스템에서 널리 연구되는 기본 작업인 RBC(Reliable Broadcast)로 축소됩니다.
구체적으로, 노드는 RBC 서브프로토콜을 통해 지속적으로 새로운 데이터 블록을 제안하고 전파하며, 이후 이러한 데이터 블록은 순서 지정 서브프로토콜을 통해 결정되고 출력됩니다.

이 설계는 대역폭 리소스 활용을 효과적으로 최적화하고 기존 방법에 비해 시스템 처리량을 크게 향상시킵니다. Supra도 이 원칙을 따르고 데이터 전송과 트랜잭션 순서를 분리합니다. 그러나 우리는 현재의 최첨단 합의 프로토콜에서도 최적화의 초점이 여전히 주로 주문 하위 프로토콜에 있다는 것을 관찰했습니다. 이는 실제로 시스템의 실제 병목 현상과 반대됩니다.

예를 들어 Tusk [11] 및 Bullshark [20]의 주요 장점은 정렬 단계에서 통신 오버헤드를 완전히 제거하는 소위 제로 메시지 정렬입니다. 하지만 앞서 지적했듯이 통신 비용의 주요 원인은 순서가 아닌 데이터 전송입니다.

그림 6은 우리의 접근 방식을 기존 솔루션과 비교합니다. 우리의 목표는 데이터 전송 단계에서 각 노드의 전송량을 줄이는 것입니다. 특히 단일 노드의 최대 전송 부하를 줄이는 것입니다. 실제 애플리케이션에서는 네트워크 대역폭이 시스템 처리량의 주요 제한 요소인 경우가 많습니다. 따라서 데이터 전송 프로세스를 최적화함으로써 시스템의 전반적인 성능과 효율성을 더욱 향상시킬 수 있습니다.

Supra의 xRBC 프로토콜

동일한 노드 집합에서 운영되는 독립적인 주문 서비스를 사용하는 혁신을 통해 데이터 전송에 따른 통신 비용을 대폭 절감합니다.

기존 접근 방식에서는 일반적으로 RBC(Reliable Broadcast) 프로토콜을 통해 데이터 전송이 수행됩니다. RBC는 방송사가 서로 다른 데이터 배치를 서로 다른 노드로 보내는 것을 방지하기 위해 시스템의 정직한 노드 중 2/3 이상이 필요합니다(즉, 발신자 모호성 문제).

그러나 우리는 독립적인 주문 서비스를 활용하여 데이터 전송을 xRBC라고 하는 완화된 RBC 작업으로 개선할 수 있음을 발견했습니다. xRBC에서는 데이터 전송을 완료하는 데 정직한 노드의 1/2 이상만 필요하므로 통신 비용이 크게 절감됩니다.

xRBC의 설계 장점

xRBC에서는 참여 노드만으로는 발신자 모호성을 완전히 방지할 수 없습니다. 이 문제를 해결하기 위해 주문 서비스는 방송사의 배치를 인증하여 정직한 노드 간의 합의를 보장하고 이를 통해 불일치를 제거합니다. 주문 서비스에는 여전히 대다수(정직한 노드의 2/3 이상) 보장이 필요하지만 xRBC는 다음 측면에서 기존 RBC에 비해 상당한 이점을 가지고 있습니다.

낮은 통신 오버헤드: 대다수의 정직한 노드에 대한 의존도를 줄임으로써 프로토콜 작동 시 통신 복잡성이 줄어듭니다.
향상된 성능: xRBC는 기존 RBC에 필적하는 보안을 유지하면서 데이터 전송을 보다 효율적으로 처리하도록 설계되었습니다.

클랜 분산 데이터 전파 활용

트랜잭션은 클랜(부족의 임의 하위 의회) 내에서만 실행되므로 트랜잭션 데이터는 처음에는 해당 클랜을 실행하는 노드로만 전송됩니다. 이는 네트워크 대역폭의 부하를 크게 줄이고 부족 전체에 데이터를 분산시키는 것보다 더 효율적입니다. 각 실행 클랜 내에서 우리는 노드의 하위 집합을 배치 제안자로 지정하여 해당 버킷에서 트랜잭션 배치를 구축하고 이를 클랜 내의 모든 노드에 전송하는 일을 담당합니다.

다른 클랜의 배치 제안자는 프로토콜 단계를 동기화하거나 기다리지 않고도 트랜잭션 배치를 독립적으로 병렬로 전파할 수 있다는 점을 언급할 가치가 있습니다. 이 병렬 비동기 전파 메커니즘은 데이터를 푸시할 때 네트워크 대역폭 활용 효율성을 극대화합니다.

또한 트랜잭션 데이터는 상태 동기화를 달성하기 위해 후속 단계에서 부족 전체에 추가로 전파될 수 있습니다(시대 전반에 걸쳐 노드 재분배를 촉진하려면 자세한 내용은 섹션 9 참조). 이러한 단계별 데이터 배포 설계는 네트워크 성능을 보장하는 동시에 시스템 일관성과 유연성을 보장합니다.

그림 7 xRBC 프로토콜

특정 프로세스(그림 7 참조)

배치 제안자는 트랜잭션 배치를 구축하고 이를 클랜 내의 모든 노드에 보내는 일을 담당합니다.
클랜 노드가 유효한 배치를 수신하면 배치의 데이터 가용성에 투표하고 투표 결과를 클랜의 모든 노드, 클랜의 다른 노드 및 지정된 게이트웨이 RPC 노드에 브로드캐스트합니다.
단순 다수결이 통과되면 시스템은 데이터 가용성 인증서(DAQC)를 생성하여 최소한 하나의 정직한 노드가 완전한 거래 데이터를 갖도록 보장합니다.
노드에 배치 데이터의 일부가 누락된 경우 단순 다수의 클랜 노드로부터 데이터를 요청할 수 있으며 DAQC는 이 요청이 충족될 것을 보장합니다.
크기 임계값을 초과하는 배치의 경우 또는 모든 클랜 노드가 배치 제안자로 사용되지 않는 경우 삭제 코딩을 도입하여 클랜 내 데이터의 균등한 배포를 보장하고 대역폭 사용 효율성을 최적화합니다.

블록 콘텐츠 및 완결성

블록에는 배치 인증서만 포함됩니다. 합의 프로토콜의 검증자(트리브 노드)가 블록 제안자 역할을 할 때 수신한 모든 DAQC 배치를 블록에 패키징합니다. 블록이 최종화되고 검증자에 의해 확인되면 검증자는 포함된 DAQC를 캐시에서 제거합니다. 해당 DAQC는 최종화된 블록에 기록되어 더 이상 보관할 필요가 없기 때문입니다.

블록에는 배치 인증서만 포함되어 있고 거래 데이터를 직접 저장하지 않기 때문에 Supra 블록체인은 실제로 매우 가벼운 블록체인입니다. 이 설계는 블록 크기를 크게 줄이고 데이터 전송 효율성을 향상시킵니다.

7. 합의 프로토콜

비잔틴 장애 허용(BFT) 합의 프로토콜: 블록체인의 핵심

BFT 합의 프로토콜은 블록체인의 핵심 구성 요소이며 블록에 대한 표준 순서를 제공하여 블록 내 트랜잭션에도 표준 순서가 있도록 보장합니다. 우리는 고전적인 PBFT(Practical Byzantine Fault Tolerance) 프로토콜에서 영감을 받아 이를 기반으로 성능 최적화를 수행한 Moonshot SMR이라는 새로운 BFT 합의 프로토콜을 혁신적으로 설계했습니다.

앞서 언급했듯이 합의 프로토콜은 부족 내에서 실행되는 반면, 거래 실행은 클랜으로 제한됩니다. 따라서 Moonshot은 탄력적인 설계를 채택하고 실제 거래 처리량 요구 사항에 따라 유연하게 적응할 수 있습니다. 블록에 거래 데이터가 직접 포함되지 않고 배치 인증서만 포함되어 시스템을 더욱 효율적이고 가볍게 만든다는 점은 주목할 가치가 있습니다.

문샷 성능

Moonshot은 다음과 같은 핵심 성과 지표를 달성합니다.

연속 제안 지연(두 블록 제안 간의 최소 지연): 1 메시지 지연(md).
제출 지연: 3md.
일괄 전파 및 데이터 가용성 인증서 생성에 대한 누적 지연: 2md.
블록은 네트워크 홉마다 제안되므로 데이터 가용성 인증서는 평균 대기열 지연 시간 0.5md로 다음 블록 제안을 기다리기 위해 대기열에 있어야 합니다.

따라서 시스템의 전체 종단 간 대기 시간은 5.5md입니다.

공식 검증: 프로토콜 보안 보장

분산 프로토콜은 동작이 복잡하고 상태 공간이 무한한 경우가 많으므로 정확성을 입증하는 것이 매우 어렵습니다. 공식 검증은 프로토콜에 오류가 없음을 수학적으로 증명할 수 있기 때문에 프로토콜 보안을 보장하는 최고의 표준입니다.

이를 위해 우리는 Microsoft의 IvY 검증자를 사용하여 Moonshot 합의 프로토콜의 보안 속성을 공식적으로 검증하고 절대 포크 기능을 엄격하게 입증하고 프로토콜의 정확성과 보안에 대한 수학적 보장을 제공했습니다.

실험적 평가

우리는 GCP(Google Cloud Platform)에 대해 광범위한 평가를 수행하여 5개 지역에 노드를 균등하게 배포했습니다.

us-east 1-b(사우스캐롤라이나)
us-west 1-a(오레곤)
Europe-north 1-a (핀란드 하미나)
아시아-북동쪽 1-a (도쿄)
호주-남동부 1-a(시드니)

실험 설정은 다음과 같습니다.

클라이언트와 합의 노드는 같은 위치에 있습니다.
각 트랜잭션은 512바이트의 무작위 데이터로 구성되며 배치 크기는 500KB로 설정됩니다.
각 실험은 180초 동안 실행됩니다.
지연 시간 측정: 트랜잭션 생성부터 결함이 없는 모든 노드의 제출까지 평균 시간을 계산하여 엔드투엔드 지연 시간을 결정합니다.
처리량 측정: 초당 완료된 트랜잭션 수를 기준으로 평가됩니다.

우리가 테스트한 아키텍처는 각각 60개의 노드로 구성된 5개의 클랜으로 나누어진 300개의 노드로 구성되었습니다(GCP 지역당 12개의 노드가 배포됨). 이 구성에서 300노드 네트워크의 클랜(60노드)이 내부 부정직한 다수로 인해 실패할 확률은 0.0107입니다.

그럼에도 불구하고 우리의 목표는 이 아키텍처의 높은 성능을 보여줄 뿐만 아니라 대규모 시스템에서도 높은 처리량과 낮은 대기 시간을 유지할 수 있음을 입증하는 것입니다.

하드웨어 구성:

우리는 각각 vCPU 32개, 128GB 메모리, 최대 16Gbps의 송신 대역폭을 갖춘 e 2-standard-32 머신을 사용했습니다.

이러한 실험을 통해 우리는 성능과 확장성 측면에서 Supra 아키텍처의 강력한 기능을 검증했습니다.

그림 8 처리량 및 종단 간 지연

그림 8과 같이 시스템 처리량과 종단 간 지연 간의 관계를 관찰했습니다.

처리량이 500,000TPS에 도달하면 종단 간 대기 시간은 1초 미만으로 유지됩니다.
300,000TPS에서 대기 시간은 약 650밀리초이며 이는 아키텍처 설계의 이론적 한계에 가깝습니다.

또한 DAQC(데이터 가용성 인증서) 생성 시간을 측정했는데, 이는 약 160밀리초였습니다.

요약하면:

거래에 대한 사전 확인 지연은 약 160밀리초입니다.
정렬 최종 대기 시간은 1초 미만입니다.

DAG 합의 프로토콜

DAG(방향성 비순환 그래프) 합의 프로토콜에 대한 연구에서 영감을 받아 Sailfish라는 새로운 DAG 합의 프로토콜을 설계했습니다. 이 프로토콜은 시스템 처리량을 희생하지 않고 제출 지연을 1개의 신뢰할 수 있는 브로드캐스트 + 1개의 메시지 지연(md)으로 최적화하여 현재 최첨단 DAG 합의 프로토콜의 성능을 능가합니다.

또한 우리는 Sailfish의 변형을 개발하고 이를 부족 클랜 아키텍처와 결합하여 시스템 처리량을 더욱 향상시켰습니다. 우리는 현재 이 디자인에 대한 광범위한 실험 테스트를 수행하고 있습니다. Sailfish가 대규모 네트워크 환경에서 기존 Moonshot 프로토콜보다 성능이 뛰어나다면 핵심 합의 프로토콜을 Sailfish로 전환하여 보다 효율적인 합의 프로세스를 달성할 계획입니다.

그림 9 Supra의 병렬 실행 방법

8.실행

블록체인의 현재 상태에는 모든 자산과 소유권 정보는 물론 모든 스마트 계약에 대한 최신 데이터가 포함되어 있습니다. 완성된 블록 트랜잭션을 실행할 때 해당 상태 부분을 로드하고, 블록 내 트랜잭션 순서대로 상태를 업데이트하고, 수정된 상태를 지속적으로 저장해야 합니다.

현대 블록체인에서는 거래 처리 능력이 지속적으로 향상되면서 거래 최종 확인의 종단 간 지연에서 실행 시간이 무시할 수 없는 중요한 요소가 되었습니다. 이러한 추세는 실행을 병렬화하여 지연 시간을 효과적으로 줄이는 Solana, Sui, Aptos 및 Monad와 같은 체인에서 특히 두드러집니다.

우리의 부족 클랜 아키텍처는 트랜잭션의 병렬 실행도 가능하지만 네트워크 수준에서 최적화되어 있습니다. 구체적으로, 거래 실행은 클랜 내에서만 이루어지며, 서로 다른 클랜이 자체 거래 일괄 처리를 병렬로 처리하므로 시스템 실행 효율성이 크게 향상됩니다(그림 9 참조).

8.1 트랜잭션의 병렬 실행

네트워크 수준에서 병렬성을 달성하는 것 외에도 단일 노드 내에서 멀티 코어 프로세서를 최대한 활용하여 트랜잭션을 병렬로 효율적으로 실행하는 방법도 탐구했습니다. 현재 문헌 및 업계에서 흔히 사용되는 병렬 실행 방법은 크게 두 가지 범주로 나뉩니다.

낙관적/예측적 실행 기술
결정론적 종속성에 기반한 사전 결정된 기술

소프트웨어 트랜잭션 메모리(STM)

STM 기술은 멀티 코어 프로그램의 병렬 실행을 위해 기존 컴퓨팅 분야에서 널리 사용됩니다. Aptos의 BlockSTM은 블록체인 거래 실행에 STM 기술을 도입합니다.

사용 가능한 모든 코어에서 병렬로 트랜잭션을 낙관적으로 실행합니다.
그런 다음 트랜잭션 간에 종속성 충돌이 있는지 확인합니다.
충돌이 발견되면 협력 스케줄러를 통해 충돌하는 트랜잭션이 다시 실행됩니다.

초혁신적인 솔루션

우리는 Aptos의 BlockSTM과 달리 스케줄러 없이 효율적으로 충돌을 해결할 수 있는 혁신적인 STM 병렬 실행 알고리즘을 제안합니다. 이 접근 방식은 성능 및 아키텍처 측면에서 BlockSTM과 유사하며, 실제 응용 분야에서의 장점을 검증하기 위해 현재 설계에 대한 심층적인 평가를 진행하고 있습니다.

액세스 사양에 따른 병렬화

일부 블록체인은 트랜잭션에 대한 액세스 패턴을 지정하여 병렬화를 구현합니다.

솔라나의 Sealevel에서는 읽고 써야 하는 계정을 명시적으로 선언하는 트랜잭션이 필요합니다.
Sui에서는 (객체 식별자를 통해) 읽고 쓸 객체를 지정하고 이러한 객체가 배타적인지 공유되는지를 선언하는 트랜잭션이 필요합니다.
Polygon의 접근 방식은 다릅니다. 블록 제안자는 BlockSTM 기술을 사용하여 블록을 실행하고, 트랜잭션 간의 종속성을 미리 계산하고, 이러한 종속성 정보를 블록에 포함시켜 다른 검증자가 독립적인 트랜잭션을 병렬로 실행할 수 있도록 합니다.

그러나 트랜잭션에서 액세스 모드를 명시적으로 선언하거나 블록에 종속성 정보를 포함하면 블록 크기가 크게 증가한다는 점에 유의하는 것이 중요합니다. 이로 인해 대역폭이 더 빨리 포화되어 시스템이 달성할 수 있는 최대 처리량이 제한될 수 있습니다.

이러한 방법을 활용하여 우리는 스마트 계약을 정적으로 분석하고 계약이 배포될 때 액세스 사양을 자동으로 도출하며 RPC 노드나 지갑 없이 이러한 사양을 블록체인 상태에 저장하는 결정론적 병렬 실행 알고리즘을 개발하고 있습니다. . 이러한 사양을 통해 최종 블록의 트랜잭션 선형 순서를 부분(완화) 순서로 최적화하여 독립적인 트랜잭션의 병렬 실행을 가능하게 합니다. 이 방법은 대역폭 사용량을 줄일 뿐만 아니라 전체 시스템의 처리량과 효율성을 향상시킵니다.

혼합 방법

우리는 정적으로 파생된 액세스 사양을 활용하여 STM 알고리즘을 개선하는 하이브리드 접근 방식이 최적화된 실행 기술의 궁극적인 형태라고 믿습니다(그림 9 참조). 우리는 현재 이 디자인에 대한 종합적인 평가를 진행하고 있습니다.

8.2 집행순서의 공정성

거래 주문의 공정성을 보장하기 위해 우리는 2단계 프로세스를 설계했습니다.

초기 무작위 순서: 합의 프로토콜은 먼저 트랜잭션의 초기 무작위 시드 순서를 생성합니다.
최종 순서: 블록 기반 BLS 임계값 서명에 의해 생성된 온체인 난수 프로토콜을 통해 최종 트랜잭션 순서가 도출되고 실제 트랜잭션 실행 순서가 결정됩니다.

배치 제안자 또는 블록 제안자는 최종 무작위 트랜잭션 실행 순서를 예측하거나 조작할 수 없기 때문에 이 추가 무작위화 계층은 최대 추출 가능 값(MEV) 공격을 효과적으로 완화합니다.

스팸 문제를 해결하기 위해 지역 수수료 시장을 도입했습니다. 분쟁 상태에서는 거래 비용이 기하급수적으로 증가하므로 시스템의 간섭 방지 능력이 향상되는 동시에 거래 주문의 효율성과 공정성이 보장됩니다.

8.3 다중 VM

이더리움은 Turing-complete 온체인 프로그래밍 환경인 EVM을 도입하여 dApp 개발의 창의성을 크게 발휘했으며 특히 DeFi 애플리케이션에 대한 강력한 지원을 제공했습니다. EVM은 Web 2.0 프로그래밍 언어의 경험을 빌려 Solidity를 탄생시켰습니다. 그러나 블록체인 기술의 발전과 함께 커뮤니티는 자산 전송 및 온체인 자산 관리를 위해 특별히 설계된 프로그래밍 언어가 필요하다는 것을 점차 깨달았습니다. 따라서 Meta의 Diem 팀은 나중에 Aptos Move 및 Sui Move와 같은 변형을 생성한 Move 언어를 개발했습니다.

Supra는 맞춤형 온체인 트랜잭션 프로그래밍 언어의 중요성을 깊이 인식하여 Move 언어를 스마트 계약 플랫폼의 첫 번째 선택으로 선택했으며 Move의 지원을 받아 L1 블록체인을 출시할 예정입니다.

동시에 다중 VM 생태계에서도 큰 잠재력을 볼 수 있습니다. 서로 다른 가상 머신 아래의 개발자는 서로를 보완하고 블록체인 산업의 혁신과 발전을 공동으로 촉진할 수 있습니다. 따라서 우리는 효율적인 다중 VM 아키텍처를 설계했습니다.

부족 클랜 아키텍처의 자연스러운 샤딩 특성을 기반으로 각 클랜은 상태 샤드를 호스팅하며, 다양한 클랜은 다양한 가상 머신을 호스팅할 수 있습니다.

Move 스마트 계약 플랫폼을 통합한 후 Supra는 EVM(Ethereum Virtual Machine)으로 더욱 확장하여 거대한 Ethereum 생태계와의 호환성을 달성할 것입니다. 다음으로, Solana Virtual Machine(SVM)을 통합하여 Rust, C, C++와 같이 널리 사용되는 프로그래밍 언어를 사용하여 스마트 계약을 구축하는 개발자를 지원할 것입니다.

결국 Supra는 CosmWasm도 지원하여 활성 Cosmos 생태계와의 원활한 연결을 가능하게 합니다.

가상 머신 간 통신

다중 VM 환경에서 사용자는 서로 다른 가상 시스템에 여러 계정을 갖고 있으며 가상 시스템 간에 자산을 전송하려고 할 수 있습니다. 또한 Supra의 기본 토큰 $SUPRA는 모든 가상 머신에서 균일하게 관리되어야 합니다. 이 문제를 해결하기 위해 우리는 간단하고 효율적인 3단계 워크플로를 제안합니다.

가상 머신 간 전송 트랜잭션을 제출합니다. 사용자는 가상 머신 간 자산 전송 트랜잭션을 시작합니다. 이 트랜잭션은 두 부분으로 구성됩니다.

소스 가상 머신의 차변 거래 tdt_dtd
대상 가상 머신의 수신 트랜잭션 tct_ctc입니다.
트랜잭션 ttt가 소스 가상 머신에서 먼저 실행되고 공제가 완료되며 해당 이벤트가 트리거됩니다.

이벤트 모니터링 및 제출: 소스 가상 머신의 클랜에서 패밀리를 무작위로 선택합니다(패밀리에는 하나 이상의 정직한 노드가 포함되어 있음). 이 노드는 공제 이벤트를 모니터링하고 계정 트랜잭션 tct_ctc를 제출하는 일을 담당합니다.
대상 가상 머신을 실행하여 대상 가상 머신의 클랜이 tct_ctc를 수신하고 실행하면 가상 머신 간 이체 프로세스가 완료됩니다.

9. 시대와 주기

Supra의 아키텍처에서는 부족에 새 노드를 추가하거나 기존 노드를 제거하는 것이 에포크 경계에서만 허용됩니다. 에포크 기간은 구성 가능하며 일반적으로 블록 수 또는 실시간으로 정의됩니다. 에포크 기간은 약 1주일로 설정할 계획입니다. 각 시대 동안 부족의 모든 노드는 합의 프로토콜을 실행하여 주문 서비스를 수행합니다.

그림 10에 표시된 것처럼 한 시대는 여러 주기(주기)로 더 나누어지며, 각 주기의 일반적인 기간은 약 하루입니다. 각 주기마다 부족의 노드는 Supra의 VRF(검증 가능한 무작위 기능)를 통해 다른 클랜에 무작위로 할당됩니다. 예를 들어:

에포크 1의 기간 2(e 1 c 2)에서 노드는 DORA 검증자 역할을 할 수 있습니다.
에포크 1의 기간 3(e 1 c 3)에서는 동일한 노드가 EVM 트랜잭션 실행 작업을 담당할 수 있습니다.

매 주기마다 노드 역할을 무작위로 재할당하는 이 메커니즘은 시스템 보안을 크게 향상시키고 특정 역할이나 기능을 표적으로 삼으려는 악의적인 행위자의 공격을 효과적으로 방어할 수 있습니다.

그림 10 시대와 주

특정 서비스(예: 서비스 SSS)를 공격하는 공격자는 서비스 SSS를 제공하는 클랜의 일부 노드를 비활성화하여 해당 서비스를 중단하려고 할 수 있습니다.

이 위협에 대응하기 위해 클랜 재구성을 위해 매 주기마다 DKG(분산 키 생성) 프로토콜이 실행됩니다. 우리는 DKG 분야의 혁신, 즉 고성능 클래스 그룹 기반 DKG 프로토콜 개발 덕분에 이러한 빈번한 재조합을 달성할 수 있습니다.

나쁜 클랜이 나타날 확률

섹션 3에서 언급했듯이 625개 노드로 구성된 부족을 5개 클랜(각각 125개 노드)으로 나누는 경우의 보안 영향을 분석합니다.

잘못된 클랜 정의: 비잔틴 노드가 클랜의 대부분을 차지합니다.
나쁜 클랜이 형성될 확률: 나쁜 클랜이 무작위로 형성될 확률은 약 35/100만입니다.

각 기간은 하루이며 클랜은 매일 재편성을 통해 노드를 재분배한다고 가정합니다. 즉, 가장 극단적인 경우(부족 내 노드의 33%가 비잔틴 행위자에 의해 통제됨)에도 나쁜 클랜이 나타날 확률은 극히 낮아 78년에 한 번만 발생할 것으로 예상됩니다.

이 극도로 낮은 확률은 거의 무시할 수 있으며 강력한 보안을 제공하는 클랜 형성 메커니즘의 신뢰성을 충분히 보여줍니다.

10.컨테이너

Supra Container는 개발자 커뮤니티를 위해 설계된 중요한 기능이며 현재 인기 있는 Appchain 개념에서 영감을 받았습니다.

우리는 애플리케이션 체인의 장점, 특히 dApp 개발자와 커뮤니티에 주권적 기능을 제공하는 고유한 가치를 충분히 인식하고 있습니다. 또한 애플리케이션 체인은 애플리케이션 기반 비즈니스 모델도 지원할 수 있습니다. 현재 Layer 2, 사이드 체인, Polkadot 파라체인, Cosmos 존 체인(Zones) 및 Avalanche 서브넷(Subnets)이 애플리케이션 체인 분야의 선도적인 솔루션입니다.

그러나 우리는 이러한 솔루션이 Supra L1과 같은 처리량이 높은 블록체인의 맥락에서는 이상적이지 않다는 것도 알고 있습니다. 애플리케이션 체인은 일반적으로 다음과 같은 주요 기능을 제공해야 합니다.

스마트 계약의 제한된 배포
맞춤형 가스 토큰
맞춤형 가스 가격

이러한 애플리케이션 체인이 보조 체인(예: 파라체인, 지역 체인, 서브넷 등)에서 호스팅되는 경우 해당 가스 가격은 해당 메인 체인(예: Polkadot Relay Chain, Cosmos Hub 또는 Avalanche C)의 가스 가격과 동일하지 않습니다. -체인) 가스 가격은 경쟁을 일으키며 메인 체인 가격에 따라 변동하지 않습니다. 이 현지화된 수수료 시장은 사용자에게 보다 예측 가능한 거래 수수료 경험을 제공하며 이는 실제 적용에 이상적입니다.

Supra 컨테이너를 통해 우리는 이러한 애플리케이션 체인의 장점과 고성능 L1 블록체인의 기능을 결합하여 개발자와 사용자를 위한 보다 유연하고 안정적인 생태 환경을 만드는 것을 목표로 합니다.

그림 11 컨테이너

Supra Container는 블록체인 분야의 새로운 개념입니다. 우리는 이를 단일 또는 관련 dApp 그룹을 제공하는 스마트 계약의 모음 또는 번들로 정의합니다. Supra 컨테이너를 통해 우리는 dApp 개발자에게 Appchain과 유사한 경험을 제공하는 동시에 다음과 같은 주목할만한 기능을 제공하기 위해 Supra의 런타임 프레임워크를 최적화했습니다.

맞춤형 가스 토큰
맞춤형 가스 가격
스마트 계약의 제한된 배포

이는 모두 매우 저렴한 비용으로 달성할 수 있으며, 완전히 새로운 보조 네트워크(예: 스테이킹 인센티브가 필요한 검증인 네트워크)를 시작하는 번거로운 프로세스를 완전히 제거합니다.

유동성 단편화 문제 해결

더 중요한 것은, 우리는 컨테이너 간 메소드 호출의 원자적 구성성을 지원함으로써 애플리케이션 체인에서 일반적으로 직면하는 주요 문제인 유동성 단편화를 극복한다는 것입니다. 이 디자인은 유동성 중앙 집중화를 유지하면서 컨테이너 간의 효율적인 상호 작용을 보장합니다.

병렬 실행 촉진

Ethereum EVM 모델에서 각 스마트 계약에는 독립적인 저장 공간이 있습니다. Supra 컨테이너를 EVM 모델에 도입한 후 블록체인 상태를 여러 파티션으로 나눌 수 있습니다.

컨테이너 내 트랜잭션은 다른 컨테이너의 상태에 영향을 주지 않고 대상 컨테이너의 상태에만 액세스합니다.
이러한 상태 격리는 컨테이너 내의 트랜잭션 실행 시간을 최적화하고 서로 다른 컨테이너 간의 충돌을 줄입니다.

이 기능을 기반으로 우리는 병렬 실행을 최적화하기 위한 간단하고 효율적인 작업 공유 대기열을 구축했습니다. 이 설계를 통해 Supra 컨테이너는 블록체인의 실행 효율성을 크게 향상시켜 개발자 경험을 단순화하고 전체 생태계의 성능 향상을 촉진합니다.

11. 결론

완전히 수직적으로 통합된 IntraLayer라는 Supra의 야심찬 비전은 수년간의 엄격한 연구 끝에 구체화되고 있습니다. IEEE Security & Privacy, Network and Distributed Security Symposium(NDSS), ACM Conference on Computer and Communications Security(CCS) 등 여러 주요 학술회의에서 다수의 연구 결과를 발표했습니다. 또한 우리는 다음을 포함하여 핵심 구성 요소에 대한 일련의 백서를 출판했습니다.