안전하고 확장 가능하며 업그레이드 가능한 Web3 인프라

요약

새로운 인터넷 인프라 블록체인의 등장으로 개발자들은 수만 개의 분산형 애플리케이션을 빠른 속도로 배포하고 있습니다. 불행히도, 낮은 안정성, 높은 비용, 낮은 처리량 및 일부 보안 문제로 인해 블록체인은 아직 널리 채택되지 않았습니다. Web3 시대에 널리 사용되기 위해서는 블록체인 인프라가 클라우드 인프라의 특성을 에뮬레이션해야 합니다. 즉, 많은 분산 응용 프로그램을 위해 신뢰할 수 있고 확장 가능하며 비용 효율적이고 지속적으로 최적화된 플랫폼을 제공해야 합니다.

이러한 문제를 해결하기 위해 확장성, 보안, 안정성 및 업그레이드 가능성을 핵심 설계 원칙으로 하는 Aptos 블록체인을 출시했습니다. 앱토스 블록체인은 지난 3년 동안 전 세계 350명 이상의 개발자들이 공동으로 개발했습니다[1]. 합의, 스마트 계약 설계, 시스템 보안, 성능 및 분산화에 새로운 혁신을 제공합니다. 이러한 기술의 조합은 Web3를 더 많은 청중에게 제공하기 위한 견고한 기반을 제공할 것입니다.

1. Aptos 블록체인은 기본적으로 Move 언어를 통합하고 사용하여 빠르고 안전한 거래 실행을 달성합니다[2]. Move 언어로 개발된 스마트 계약용 정식 검증 도구인 Move Prover는 계약 상수 및 작업에 대한 추가 보증을 제공합니다. 이 보안 중심 접근 방식을 통해 개발자는 악의적인 엔터티로부터 소프트웨어를 더 잘 보호할 수 있습니다.

2. Aptos 데이터 모델은 유연한 키 관리 및 하이브리드 호스팅 옵션을 허용합니다. 이는 사전 서명 트랜잭션 투명성 및 실용적인 라이트 클라이언트 프로토콜과 함께 더 안전하고 신뢰할 수 있는 사용자 경험을 제공합니다.

3. 높은 처리량과 낮은 대기 시간을 달성하기 위해 Aptos 블록체인은 트랜잭션 처리의 주요 단계에서 파이프라인 및 모듈식 접근 방식을 사용합니다. 특히 트랜잭션 배포, 블록 메타데이터 순서 지정, 병렬 트랜잭션 실행, 일괄 저장 및 원장 확인과 같은 작업이 동시에 실행됩니다. 이 접근 방식은 사용 가능한 모든 하드웨어 리소스를 최대한 활용하고 하드웨어 효율성을 개선하며 높은 수준의 병렬 처리를 달성합니다.

4. 읽고 쓰기 전에 읽고 쓸 데이터를 얻어야 트랜잭션의 원자성을 파괴하는 병렬 실행 엔진과 달리 Aptos 블록체인은 개발자에게 이러한 제한을 설정하지 않습니다. 애플리케이션에 더 높은 처리량과 더 낮은 대기 시간을 제공하고 복잡한 트랜잭션의 원자성을 보장하여 개발을 단순화합니다.

5. Aptos 모듈식 아키텍처는 클라이언트의 유연성을 보장하고 빈번한 업그레이드에 최적화되어 있습니다. 또한 새로운 기술 혁신을 신속하게 배포하고 새로운 Web3 사용 사례를 지원하기 위해 Aptos 블록체인은 임베디드 온체인 변경 관리 프로토콜을 제공합니다.

6. Aptos 블록체인은 단일 유효성 검사기의 성능을 넘어서는 미래 이니셔티브를 실험하고 있습니다: 모듈식 설계 및 병렬 실행 엔진은 유효성 검사기의 내부 샤딩을 지원하고 동종 상태 샤딩(동종 상태 샤딩)은 수평 처리량을 제공합니다. 노드 운영자에게 추가 복잡성을 도입합니다.

[1] 법적 고지: 이 백서와 그 내용은 토큰 판매를 제안하거나 토큰 구매를 유도하기 위한 제안이 아닙니다. 우리는 오로지 대중의 피드백과 의견을 수용하기 위해 이 백서를 게시합니다. 이 문서의 어떠한 내용도 Aptos 블록체인 또는 해당 토큰(있는 경우)이 가치를 개발, 활용 또는 축적하는 방법에 대한 보증 또는 약속으로 해석되어서는 안 됩니다. Aptos는 재량에 따라 변경될 수 있으며 성공 여부는 통제할 수 없는 여러 요인에 따라 현재 계획의 개요만 설명했습니다. 그러한 미래 진술은 필연적으로 알려진 위험과 알려지지 않은 위험을 수반하며, 이로 인해 미래 기간의 실제 성과와 결과가 이 백서에서 우리가 설명하거나 암시한 것과 실질적으로 다를 수 있습니다. Aptos는 계획을 업데이트할 의무가 없습니다. 실제 결과와 향후 이벤트가 실질적으로 다를 수 있으므로 백서의 모든 진술이 정확하다고 보장할 수 없습니다. 향후 진술에 과도하게 의존하지 마십시오.

1. 전문

Web2 시대에는 커뮤니케이션, 소셜 미디어, 금융, 게임, 쇼핑, 오디오 및 비디오 스트리밍 미디어와 같은 서비스가 사용자 데이터 권한을 가진 중앙 집중식 회사(예: Google, Amazon, Apple 및 Meta)에서 제공됩니다. 이러한 회사는 애플리케이션별 소프트웨어를 활용하여 대상 사용 사례에 대한 개발 인프라를 최적화하고 클라우드 인프라를 사용하여 해당 애플리케이션을 사용자에게 배포합니다. 클라우드 인프라는 가상 머신(VM) 대여 및 전 세계 데이터 센터(예: AWS, Azure, Google Cloud)에서 실행되는 베어 메탈 하드웨어와 같은 가상 또는 물리적 인프라 서비스에 대한 액세스를 제공합니다. 결과적으로 수십억 명의 사용자로 확장할 수 있는 Web2 인터넷 서비스를 구축하는 것이 오늘날보다 훨씬 쉬워졌습니다. 그러나 Web2는 사용자가 중앙 집중식 엔터티를 명시적으로 신뢰하도록 요구하며, 이는 점점 더 사회적 관심을 불러일으키는 요구 사항입니다.

이러한 문제를 해결하기 위해 Web3라는 새로운 인터넷 시대가 시작되었습니다. 인터넷의 웹 3 버전에서 블록체인은 분산되고 변경 불가능한 원장을 제공하여 사용자가 통제하는 중개자나 중앙 집중식 엔터티를 신뢰할 필요 없이 안전하고 안정적으로 서로 통신할 수 있도록 합니다. Web2 인터넷 서비스 및 애플리케이션이 클라우드 인프라에 의존하는 방식과 유사하게 분산형 애플리케이션은 블록체인을 분산형 인프라 계층으로 사용하여 전 세계 수십억 명의 사용자에게 다가갈 수 있습니다.

그러나 많은 블록체인의 존재에도 불구하고 Web3는 아직 널리 채택되지 않았습니다[3]. 기술이 산업을 계속 발전시키는 동안 기존 블록체인은 여전히 신뢰할 수 없습니다. 비싼 거래 수수료, 낮은 처리량, 보안 문제로 인한 빈번한 자산 손실, 실시간 대응 지원 불가. Web2 서비스를 강화하고 수십억 명의 사람들에게 성공적으로 도달하는 클라우드 인프라와 비교할 때 블록체인은 아직 Web3 애플리케이션을 동일한 높이로 가져오지 못했습니다.

2. 압토스 비전

Aptos의 비전은 Web3에 대한 주류 채택을 가져올 수 있는 블록체인을 제공하고 탈중앙화 애플리케이션의 생태계를 강화하여 실제 사용자의 고충을 해결하는 것입니다. 우리의 임무는 유연한 모듈식 블록체인 아키텍처를 제공하여 블록체인의 신뢰성, 보안 및 성능을 새로운 차원으로 끌어올리는 것입니다. 아키텍처는 빈번한 업그레이드, 최신 기술의 신속한 채택, 새로운 사용 사례에 대한 동급 최고의 지원을 지원해야 합니다.

우리는 커뮤니티 거버넌스에 의해 운영되는 분산되고 안전하며 확장 가능한 네트워크를 구축하는 것을 구상합니다. 인프라에 대한 수요가 전 세계적으로 증가함에 따라 블록체인 컴퓨팅 리소스는 이러한 수요를 충족하기 위해 수평 및 수직으로 확장됩니다. 새로운 사용 사례와 기술 발전이 등장함에 따라 네트워크는 사용자를 방해하지 않으면서 자주 원활하게 업그레이드되어야 합니다. 사용자가 더 이상 인프라 관련 문제에 주의를 기울이지 않도록 합니다. 개발자와 사용자는 키 복구, 데이터 모델링, 스마트 계약 표준, 리소스 사용량 절충, 개인 정보 보호 및 구성 가능성에 대한 다양한 옵션에 액세스할 수 있습니다. 사용자는 자신의 자산이 안전하고 사용 가능하며 거의 무료로 액세스할 수 있다고 확신합니다. 누구나 전 세계의 신뢰할 수 없는 당사자와 불변의 거래를 안전하고 쉽게 수행할 수 있습니다. 블록체인은 클라우드 인프라만큼 유비쿼터스가 될 것입니다.

이 비전을 실현하기 위해서는 상당한 기술 발전이 이루어져야 합니다. 지난 3년 동안 Diem 블록체인(Aptos 블록체인의 이전 버전)을 개발, 업그레이드 및 배포한 경험은 네트워크가 클라이언트를 방해하지 않고 프로토콜을 지속적으로 업그레이드할 수 있음을 입증했습니다[4]. 2020년 초, Diem 메인넷은 여러 지갑 공급자와 함께 12개의 노드에 배포되었습니다. 다음 해에 우리 팀은 합의 프로토콜과 핵심 프레임워크에 대한 두 가지 주요 업그레이드를 수행했습니다. 두 업그레이드 모두 사용자의 다운타임 없이 완료되었습니다. Aptos 블록체인에서 우리는 Diem 블록체인에서 영감을 받은 핵심 기능으로 보안, 투명성 및 빈번한 업그레이드를 취하면서 기술 스택에 대한 일련의 급진적인 개선을 이루었습니다. 우리는 거래 처리의 새로운 방법(섹션 7에서 설명)과 탈중앙화 및 네트워크 거버넌스에 대한 새로운 접근 방식에 특히 중점을 둡니다.

앱토스 블록체인의 지속적인 개선과 발전으로 프로토콜과 디자인을 지속적으로 업데이트하고 그때그때 최신 버전의 백서를 공개할 예정입니다. 다음에서는 앱토스 블록체인의 현재 상태와 향후 계획에 대해 설명합니다.

3. 개요

그림 1에서 볼 수 있듯이 Aptos 블록체인은 BFT(Byzantine Fault Tolerance) 및 POS(Proof of Stake) 합의 메커니즘을 사용하여 사용자 트랜잭션을 수신하고 처리하는 유효성 검사기(Validators) 그룹으로 구성됩니다. 토큰 소유자는 선택한 유효성 검사기(Validator)에서 토큰을 잠그거나 약속합니다. 각 검증인의 합의된 투표 가중치는 스테이킹된 토큰의 양에 비례합니다. 유효성 검사기는 활성화되어 합의 결정에 참여할 수 있습니다. 마찬가지로, 검증 노드에 약정 토큰이 충분하지 않거나, 검증자 세트에서 제외되거나, 블록체인 상태를 동기화할 때 오프라인 상태이거나, 합의 프로토콜이 저조한 과거 성능으로 인해 합의 참여를 거부하는 경우, 검증자는 비활성 상태일 수도 있습니다.

클라이언트는 트랜잭션을 제출하거나 블록체인의 상태 및 기록을 쿼리해야 하는 시스템의 일부입니다. 클라이언트는 유효성 검사기가 서명하고 확인한 데이터를 다운로드하고 확인할 수 있습니다. *풀 노드*는 검증자 노드 또는 네트워크의 다른 전체 노드에서 트랜잭션 및 블록체인 상태를 복제하는 클라이언트입니다. 그들은 충분한 저장 공간을 되찾기 위해 필요에 따라 일부 거래 내역과 블록체인 상태 기록을 정리할 수 있습니다. 라이트 클라이언트는 현재 검증 노드 세트만 유지하고 전체 노드에서 부분 블록체인 상태를 안전하게 쿼리할 수 있습니다. 지갑은 라이트 클라이언트의 일반적인 예입니다.

광범위한 채택을 위해 안전하고 빠르고 안정적이며 확장 가능한 Web3 인프라에 대한 요구를 충족하기 위해 Aptos 블록체인은 다음과 같은 핵심 설계 원칙을 기반으로 구축되었습니다.

• 새로운 스마트 계약 프로그래밍 언어 Move[5]를 통해 온체인 로직의 빠르고 안전한 실행은 물론 간단한 감사 가능성과 절차적 분석 가능성을 제공합니다. Aptos 블록체인은 Diem 블록체인에서 상속되어 계속해서 Move를 개발합니다.
• 일괄 처리, 파이프라인 및 병렬화된 트랜잭션 처리 방법을 통해 매우 높은 처리량과 짧은 대기 시간이 달성됩니다.
• 읽거나 쓸 데이터를 미리 식별하고 트랜잭션의 원자성을 파괴하는 기존 병렬 실행 엔진과 달리 앱토스 블록체인은 Block-STM 기술을 병렬 실행 엔진으로 혁신적으로 사용하여 임의의 복잡한 트랜잭션 성의 원자성을 효과적으로 지원합니다.
• 빠르고 스테이킹된 검증인 회전과 검증인의 평판 추적을 통해 성능과 분산형 거버넌스를 최적화합니다.
• 업그레이드 가능성과 구성 가능성은 인프라가 새로운 사용 사례와 최신 기술을 수용할 수 있도록 하는 가장 중요한 설계 원칙입니다.
• 원활한 배포를 위한 위협 모델링 및 모듈식 설계와 같은 엄격한 구성 요소 수준 테스트를 통과하여 높은 보안 및 운영 안정성을 보장합니다.
• 분산된 수평 처리량 확장성을 보장합니다. 프로그램 및 데이터 모델에서 파생된 샤딩은 수평 확장에서 중요한 개념입니다.

4장에서는 개발자가 Move 언어를 통해 Aptos 블록체인과 상호 작용하는 방법을 설명합니다. 5장에서는 논리적 모델에 대해 설명합니다. 6장에서는 Aptos 블록체인이 강력한 검증 방법을 통해 안전한 사용자 경험을 가능하게 하는 방법을 자세히 설명합니다. 7장에서는 파이프라이닝, 일괄 처리 및 병렬화와 관련된 주요 성능 혁신에 대해 설명합니다. 8장에서는 상태를 다른 노드와 동기화하기 위해 다양한 유형의 클라이언트에 대한 다양한 옵션을 자세히 설명합니다. 9장에서는 커뮤니티 소유권 및 거버넌스에 대한 계획을 설명합니다. 마지막으로 10장에서는 탈중앙화를 유지하면서 향후 성과 방향에 대해 논의합니다.

4. 프로그래밍 언어 이동

Move는 보안과 유연성에 중점을 둔 새로운 스마트 계약 프로그래밍 언어입니다. Aptos 블록체인은 Move의 객체 모델을 사용하여 원장 상태(섹션 5.5 참조)를 나타내고 Move 코드(모듈)를 사용하여 상태 전환 규칙을 인코딩합니다. 사용자가 제출한 트랜잭션에는 새 모듈 게시, 기존 모듈 업그레이드, 모듈에 정의된 인터페이스 기능 실행 및 모듈의 공용 인터페이스와 직접 상호 작용할 수 있는 스크립트가 포함될 수 있습니다.

Move 에코시스템에는 컴파일러, 가상 머신 및 기타 여러 개발 도구가 포함됩니다. Move는 Rust 프로그래밍 언어에서 영감을 받아 선형 유형과 같은 개념을 통해 데이터의 소유권을 명확히 하고 자원의 희소성, 보존 및 액세스 제어를 강조합니다. 이동 모듈은 각 리소스의 수명 주기, 저장 및 액세스 모드를 정의합니다. 이를 통해 적절한 자격 증명 없이 코인과 같은 리소스를 발행할 수 없고, 이중으로 사용할 수 없으며, 사라지지 않습니다.

신뢰할 수 없는 코드가 있는 경우에도 Move는 여전히 바이트코드 검증 도구를 활용하여 유형 및 메모리 안전을 보장할 수 있습니다. 보다 믿을 수 있는 코드 작성을 돕기 위해 Move에는 주어진 사양에 따라 Move 프로그램의 기능적 정확성을 검증할 수 있는 유형 검증 프로그램인 Move Prover[6]가 포함되어 있으며 이러한 유형 검증 기능은 Move 언어에 통합되었습니다.

사용자 계정 및 해당 계정 내용 외에도 분산 원장의 상태에는 Aptos 블록체인의 온체인 구성도 포함됩니다. 이 네트워크 구성에는 현재 활성 검증자 세트, 서약 속성 및 Aptos 블록체인 내의 다양한 서비스 구성이 포함됩니다. Move의 모듈 업그레이드 가능성 및 전체 프로그램 가능성 지원은 원활한 구성 변경을 가능하게 할 뿐만 아니라 Aptos 블록체인 자체에 대한 업그레이드 지원을 가능하게 합니다(이러한 유형의 업그레이드는 모두 프라이빗 메인넷에서 여러 번 수행되었으며 다운타임 기록이 없습니다).

Aptos 팀은 더 넓은 범위의 Web3 사용 사례를 지원하기 위해 Move 기능을 추가했습니다. 아래 섹션 5.5에 설명된 대로 Aptos 블록체인은 세분화된 리소스 제어를 가능하게 합니다. 이 기능은 병렬 실행을 효과적으로 지원할 뿐만 아니라 데이터 액세스 및 변경 비용을 거의 수정합니다. 또한 Aptos 블록체인은 세분화된 스토리지 위에 구축된 테이블 지원을 제공하여 단일 계정에서 대규모 데이터 세트(예: 대규모 NFT 컬렉션)를 구현할 수 있습니다. 동시에 Aptos는 온체인에 완전히 구현된 공유 또는 자동화 계정을 지원합니다. 이를 통해 복잡한 분산형 자율 조직(DAO)이 계정을 공유하고 이 계정을 이기종 리소스 모음의 컨테이너로 사용할 수 있습니다.

5. 논리적 모델

Aptos 블록체인의 원장 상태는 체인의 모든 계정 상태를 나타냅니다. 원장 상태는 현재 시스템에서 실행되는 트랜잭션 수에 해당하는 버전 구분을 위해 부호 없는 64비트 정수를 사용합니다. 누구나 Aptos 블록체인에 트랜잭션을 제출하여 원장의 상태를 수정할 수 있습니다. 트랜잭션이 실행된 후 트랜잭션 출력이 생성됩니다. 트랜잭션의 출력은 원장 상태(쓰기 세트라고 함), 결과 이벤트 세트(섹션 5.1.1 참조), 소비된 가스 및 실행된 트랜잭션의 상태를 조작하기 위한 0개 이상의 작업으로 구성됩니다.

5.1 거래

서명된 트랜잭션에는 다음 정보가 포함됩니다.

• 트랜잭션 인증자: 발신자는 하나 이상의 디지털 서명이 포함된 트랜잭션 인증자를 사용하여 트랜잭션이 인증되었는지 확인합니다.
• 발신자 주소: 발신자의 계정 주소입니다.
• 페이로드: 페이로드는 체인에 있는 기존 인터페이스 기능을 참조하거나 인라인 바이트코드로 실행될 기능(스크립트라고 함)을 포함합니다. 또한 입력 매개변수 세트는 바이트 배열로 인코딩됩니다. P2P 거래의 경우 입력 매개변수에는 수신자의 정보와 이체 금액이 포함됩니다.
• 가스 가격(지정된 통화/가스 단위): 발신자가 거래를 실행하기 위해 지불하고자 하는 가스 단위당 금액입니다. 가스 요금은 컴퓨팅, 네트워킹 및 저장 비용 지불을 의미합니다. 가스는 본질적인 실제 가치가 없는 추상적 계산 단위입니다.
• 최대 가스 양: 최대 가스는 트랜잭션이 중단되기 전에 소비할 수 있는 최대 가스 단위 수입니다. 적어도 가스 단가에 계정의 최대 가스 단위 수를 곱한 잔액이 있어야 합니다. 그렇지 않으면 확인 과정에서 거래가 종료됩니다.
• SequenceNumber: 트랜잭션의 시퀀스 번호입니다. 트랜잭션의 시퀀스 번호는 트랜잭션이 실행될 때 보낸 사람의 계정에 저장된 시퀀스 번호와 일치해야 합니다. 트랜잭션이 성공적으로 실행된 후 계정 시퀀스 번호가 증가하여 재생 공격을 방지합니다.
• 만료 시간: 트랜잭션이 더 이상 유효하지 않게 되는 시간 스탬프입니다.
• 블록체인 ID: 블록체인에서 트랜잭션의 유효성을 식별하여 서명 오류로부터 사용자를 추가로 보호합니다.

각 버전 i에서 상태 변경은 각각 트랜잭션, 트랜잭션 출력 및 트랜잭션 후 원장 상태를 포함하는 튜플(Ti, Oi, Si)로 표시됩니다. 결정적 함수 적용이 주어지면 트랜잭션 Ti, 원장 상태 Si-1을 실행하고 트랜잭션 출력 Oi 및 새로운 원장 상태 Si를 생성합니다. 즉, Apply(Si-1*,Ti*) → 〈Oi,Si〉이다.

5.1.1 이벤트

트랜잭션 실행 중에 이벤트가 발생합니다. 각 이동 모듈은 자체 이벤트를 정의하고 실행 시 이벤트를 내보낼 시기를 선택할 수 있습니다. 예를 들어 송금하는 동안 발신자와 수신자의 계정은 각각 SentEvent와 ReceivedEvent를 내보냅니다. 데이터는 원장에 저장되며 Aptos 노드를 통해 쿼리할 수 있습니다. 등록된 각 이벤트에는 이벤트 세부 정보를 쿼리하는 데 사용할 수 있는 고유 인덱스가 있습니다.

동일한 이벤트 인덱스로 생성된 여러 이벤트는 0부터 증가하는 숫자, 유형 및 데이터를 포함하는 각 항목이 포함된 이벤트 목록인 이벤트 스트림을 생성합니다. 모든 이벤트는 어떤 유형으로 정의되어야 합니다. 특히 제네릭을 사용할 때 동일하거나 유사한 유형으로 정의된 여러 다른 이벤트가 있을 수 있습니다. 이벤트에는 관련 데이터가 있습니다. Move 모듈 개발자를 위한 일반적인 원칙은 데이터를 변경하고 이벤트를 전송한 트랜잭션 실행 전후에 발생한 기본 리소스 변경 사항을 이해하기 위해 필요한 모든 데이터를 포함하는 것입니다.

트랜잭션은 이벤트를 생성할 수만 있고 읽을 수는 없습니다. 이 디자인은 이전에 생성된 이벤트와 같은 기록 정보가 아닌 현재 트랜잭션의 현재 상태 및 입력만으로 트랜잭션을 실행할 수 있도록 합니다.

5.2 계정

각 계정은 계정 주소라고 하는 고유한 256비트 값으로 식별됩니다. 기존 계정이 트랜잭션을 보낼 때 create_account(addr) Move 함수를 호출하여 생성할 수 있는 원장 상태(5.5절 참조)에서 새 계정을 만듭니다. 이것은 일반적으로 트랜잭션이 아직 생성되지 않은 계정 주소로 Aptos 토큰을 보내려고 시도할 때 발생합니다. 편의를 위해 Aptos는 이체(from, to, amount) 기능도 지원하는데, 이체 전에 계정이 존재하지 않는 경우 기본적으로 계정을 생성합니다.

새 계정을 만들기 위해 사용자는 먼저 서명 키 쌍(vk,sk)을 생성합니다. 다음으로 서명방식 식별자(ssid)를 공개키 vk와 함께 접합하고 암호화된 해시 H를 통해 특정 서명방식의 새로운 계정 주소를 얻는다: addr=H(vk, ssid).

주소 addr에서 새 계정을 생성한 후 사용자는 개인 키 sk를 사용하여 서명하여 addr의 계정에서 보낼 트랜잭션에 서명할 수 있습니다. 사용자는 또한 sk를 능동적으로 변경하거나 가능한 개인 키 유출에 대응하여 sk를 회전할 수 있습니다. 계정 주소는 공개 키에서만 생성되기 때문에 개인 키 변경 작업은 계정 주소를 변경하지 않습니다.

Aptos 블록체인은 계정을 실제 ID에 연결하지 않습니다. 사용자는 여러 키 쌍을 생성하여 여러 계정을 만들 수 있습니다. 동일한 사용자가 관리하는 계정은 본질적으로 서로 연결되어 있지 않습니다.

그러나 자산 관리의 용이성을 위해 단일 사용자는 여전히 하나의 지갑에서 여러 계정을 관리할 수 있습니다. 섹션 7.4에서 설명한 것처럼 사용자 또는 사용자 그룹이 소유한 여러 계정은 실행 동시성을 높일 수 있는 방법도 제공합니다.

5.3 모듈 이동

Move 모듈에는 데이터 유형(구조) 및 프로시저를 선언하는 Move 바이트코드가 포함되어 있습니다. 모듈 이름과 함께 모듈을 선언하는 계정의 주소로 식별됩니다. 예를 들어 그림 2의 첫 번째 통화 모듈에 대한 식별자는 0x1::coin입니다. 모듈은 그림 2의 지갑 모듈에 표시된 것처럼 체인의 다른 모듈에 의존할 수 있으며 다른 모듈의 코드를 재사용할 수 있습니다.

모듈은 계정 내에서 고유해야 합니다. 즉, 모듈 이름은 각 계정에서 고유해야 합니다. 예를 들어 그림 2에서 주소가 0x1인 계정은 coin이라는 이름의 다른 모듈을 요청할 수 없습니다. 반면에 주소 0x3의 계정은 coin이라는 모듈을 선언할 수 있으며 이 모듈의 식별자는 0x3:coin이 됩니다. 0x1::coin::Coin과 0x3::coin::Coin은 서로 다른 유형이며 상호 교환적으로 사용할 수 없으며 공통 모듈 코드를 공유하지 않습니다. 반대로 0x1::coin::Coin과 0x1::coin::Coin>은 동일한 제네릭 유형의 다른 인스턴스이며 상호 교환적으로 사용할 수 없지만 공통 모듈 코드를 공유할 수 있습니다.

동일한 주소 아래의 모듈은 동일한 *패키지(패키지)*로 병합됩니다. 이 주소의 소유자는 바이트코드 및 패키지 메타데이터를 포함하여 전체 온체인으로 패키지를 게시합니다. 패키지 메타데이터는 패키지가 업그레이드 가능한지 또는 변경할 수 없는지 여부를 결정합니다. 업그레이드 가능한 소프트웨어 패키지의 경우 업그레이드가 허용되기 전에 호환성 검사가 수행됩니다. 기존 인터페이스 기능은 변경할 수 없으며 리소스를 메모리에 저장할 수 없습니다. 그러나 업그레이드를 통해 새로운 기능과 리소스를 추가할 수 있습니다.

Aptos 프레임워크는 정기적으로 업그레이드 가능한 모듈 패키지로 정의된 Aptos 블록체인의 핵심 라이브러리 및 구성으로 구성됩니다(섹션 9.2 참조).

그림 3: 온체인 데이터의 예

5.4 자원

모듈과 유사하게 계정 주소도 이와 관련된 데이터 값을 가질 수 있습니다. 각 계정 주소에서 데이터 값은 해당 유형에 따라 결정되며 각 계정에서 각 유형의 데이터 값은 고유해야 합니다. 그림 3을 예로 사용하면 주소 0x50은 단일 값을 보유하며 여기서 0x3::coin::Coin은 정규화된 유형입니다. 0x3은 Coin 모듈의 주소, Coin은 모듈의 이름, Coin은 데이터 유형의 이름입니다. 일반 데이터 값도 사용할 수 있으며 다른 일반 인스턴스는 다른 유형으로 취급됩니다. 이것은 다른 인스턴스가 동일한 기능 코드를 공유할 수 있도록 하는 확장성에 매우 중요합니다.

값을 변경, 삭제 및 게시하기 위한 규칙은 데이터 유형을 정의하는 모듈에서 인코딩됩니다. Move의 보안 및 유효성 검사 규칙은 다른 코드나 엔터티가 다른 모듈에 정의된 데이터 유형의 인스턴스를 직접 생성, 수정 또는 삭제하는 것을 방지합니다.

주소 아래에 각 유형에 대해 최대 하나의 최상위 값을 갖는 것은 제한적으로 들립니다. 그러나 이것은 실제로 문제가 되지 않습니다. 개발자가 멤버 변수와 동일한 유형의 데이터로 다른 래퍼 유형을 정의하여 제한을 피할 수 있기 때문입니다. Wallet 구조(그림 3)는 래퍼 유형을 사용하는 방법의 예입니다.

또한 모든 데이터 유형을 온체인에 저장할 수 있는 것은 아닙니다. 데이터 인스턴스가 최상위 값으로 규정되려면 데이터 유형에 키 기능이 있어야 합니다. 또한 중첩 값에는 Store 기능이 필요합니다. 두 가지 기능이 있는 데이터 유형을 리소스라고도 합니다.

5.5 원장 상태

Move virtual machine(Move VM)의 관점에서 각 계정은 일련의 값과 키-값 데이터 구조로 구성됩니다. 이러한 데이터 구조를 항목이라고 하며 이진 정규화 직렬화 형식(BCS)으로 저장됩니다. 이러한 데이터 구조 설계를 통해 개발자는 적은 양의 데이터를 다수의 계정에 복사할 때 효율적으로 실행할 수 있는 스마트 컨트랙트를 작성할 수 있으며, 많은 양의 데이터를 집중시킬 때도 효율적으로 실행할 수 있는 스마트 컨트랙트를 작성할 수 있습니다. 소수의 계정. 이동 모듈은 계정 데이터와 유사하게 저장되지만 별도의 네임스페이스에 저장됩니다. Genesis 원장 상태는 초기 계정 집합과 블록체인이 초기화될 때 관련 상태를 정의합니다.

출시 시 Aptos 블록체인은 단일 원장 상태로 표시됩니다. 그러나 사용이 확산되고 기술이 발전함에 따라 Aptos는 샤드 수를 확장하여 처리량을 늘리고(즉, 여러 원장 상태 활성화) 샤드 간에 자산을 이동하거나 액세스하는 트랜잭션을 지원할 것입니다. 각 원장 상태는 특정 샤드의 모든 온체인 자산을 유지하고 동일한 계정 모델과 세분화된 키-값 데이터 스토리지를 제공하여 스토리지 액세스에 거의 고정된 비용을 제공합니다.

6. 안전한 사용자 경험

수십억 명의 인터넷 사용자에게 도달하려면 Web3의 사용자 경험이 안전하고 편리해야 합니다. 이 섹션에서는 이 목표를 달성하기 위한 Aptos 블록체인의 몇 가지 혁신에 대해 설명합니다.

6.1 거래 타당성 보호

트랜잭션에 서명한다는 것은 서명자가 해당 트랜잭션을 제출하고 실행하도록 블록체인에 권한을 부여한다는 것을 의미합니다. 때로는 사용자가 주의를 기울이지 않거나 조작되고 있다는 사실을 깨닫지 못한 채 트랜잭션에 서명합니다. 이러한 위험을 줄이기 위해 Aptos 블록체인은 트랜잭션의 가능성을 제한하고 서명자가 무한한 확인 작업에 갇히지 않도록 보호합니다. 현재 Aptos는 보낸 사람의 일련 번호, 트랜잭션 만료 시간 및 지정된 체인 ID의 세 가지 보호 수단을 제공합니다.

트랜잭션의 시퀀스 번호는 보낸 사람의 계정당 한 번만 제출할 수 있습니다. 따라서 발신자가 현재 계정 시퀀스 번호 ≥ 트랜잭션 t의 시퀀스 번호를 발견하면 t는 이미 커밋되었거나 t는 커밋되지 않습니다(t가 사용하는 시퀀스 번호는 이미 다른 트랜잭션에서 가져왔기 때문).

블록체인 시간은 높은 정밀도와 높은 빈도(일반적으로 1초 미만)로 진행됩니다. 자세한 내용은 섹션 7.3.1을 참조하십시오. 블록체인 시간이 트랜잭션 t의 만료 시간을 초과하면 다시 t가 커밋되거나 t가 커밋되지 않습니다.

각 트랜잭션에는 서로 다른 블록체인 환경(예: 테스트넷 및 메인넷) 간에 악의적인 엔터티의 재생 공격을 방지하기 위해 할당된 체인 ID가 있습니다.

6.2 이동 기반 키 관리

섹션 5.2에서 언급한 바와 같이 Aptos 계정은 개인 키 유출, 원격 공격 및 기존 암호화 알고리즘의 향후 크래킹 위험을 줄이는 중요한 기능인 키 순환(키 순환)을 지원합니다. 또한 Aptos 계정은 사용자가 하나 이상의 관리인 및 기타 신뢰할 수 있는 엔터티에 계정 개인 키를 회전하는 기능을 위임할 수 있는 새로운 하이브리드 보관 모델을 지원할 수 있을 만큼 유연합니다. 그런 다음 이러한 신뢰할 수 있는 엔터티가 특정 상황에서 키를 회전할 수 있도록 하는 정책이 이동 모듈을 통해 정의됩니다. 예를 들어, 엔터티는 많은 신뢰할 수 있는 당사자가 보유한 kout-of-n 다중서명 키일 수 있으므로 사용자 키가 분실된 경우 키 복구 서비스를 제공합니다(예: 비트코인의 20%가 현재 계정에 잠겨 있습니다[7]). .

또한 많은 지갑이 클라우드 지원 개인 키, 다자간 계산 및 소셜 복구와 같은 다양한 키 복구 체계를 제공하지만 이러한 체계는 블록체인 구현(즉, 오프체인)을 기반으로 하지 않습니다. 따라서 각 지갑은 자체 키 관리 체계를 구현해야 하며 사용자에게는 키 관리가 블랙박스가 됩니다. 이에 반해 앱토스의 키 관리 기능은 완전하고 투명한 키 관리 운영을 제공하는 동시에 지갑 키 관리 솔루션 구현의 어려움을 크게 줄여줍니다.

6.3 사전 서명된 거래 투명성

오늘날 지갑은 서명하는 거래에 대해 대부분 불투명합니다. 따라서 사용자는 종종 악의적인 거래에 속아 자금 손실과 일련의 심각한 결과를 초래합니다. 체인의 각 트랜잭션 데이터를 쿼리할 수 있는 블록체인도 이러한 손실을 피할 수 없습니다. 현재 사용자 보호 장치가 거의 없기 때문에 사용자는 다양한 공격에 노출됩니다.

이 문제를 해결하기 위해 Aptos 생태계는 트랜잭션 사전 실행 서비스를 제공합니다. 트랜잭션 결과(사람이 읽을 수 있는 형식)는 사용자가 서명하기 전에 사용자에게 제공됩니다. Aptos는 트랜잭션 사전 실행 서비스를 이전에 알려진 공격 및 악의적인 스마트 계약과 결합하여 사기를 줄이는 데 도움을 줄 것입니다. 또한 Aptos는 지갑이 실행 중에 트랜잭션에 제한을 가할 수 있도록 합니다. 이러한 제한 사항을 위반하면 악의적인 애플리케이션이나 사회 공학 공격으로부터 사용자를 보호하기 위해 트랜잭션이 중단됩니다.

6.4 실용적인 라이트 클라이언트 프로토콜

단순히 API 공급자의 TLS/SSL 인증서에 의존하여 블록체인 클라이언트와 서버 간의 신뢰를 구축하는 것은 클라이언트를 적절하게 보호하지 못합니다. 유효한 인증서가 있더라도 지갑과 클라이언트는 그들에게 제공된 데이터의 진위와 무결성을 보장할 수 없습니다. 따라서 API 공급자는 거짓 또는 악의적인 블록체인 데이터를 반환하고 제3자를 속이고 이중 지출 공격을 수행할 수 있습니다.

그림 4: 트랜잭션 처리 수명 주기의 모든 단계는 완전히 독립적이며 병렬화될 수 있습니다.

이를 방지하기 위해 Aptos는 지갑과 클라이언트가 신뢰할 수 없는 타사 서버에서 제공하는 데이터의 유효성을 확인하는 데 사용할 수 있는 상태 증명 및 라이트 클라이언트 확인 프로토콜을 제공합니다. 또한 섹션 7.6.2에 설명된 대로 타임스탬프 기반 상태 증명을 사용하여 라이트 클라이언트는 네트워크 구성의 변경 사항(*에포크 변경)*을 추적하거나 현재 신뢰할 수 있는 노드(*앵커)*에서 동기화할 수 있습니다. 상태 [8], 계정 상태를 실시간(예: 몇 초 이내)으로 유지합니다. 빈도가 높은 타임스탬프와 저렴한 상태 증명을 통해 Aptos는 고객에게 안전한 서비스를 제공합니다.

또한 Aptos 노드는 풍부한 고성능 스토리지 인터페이스를 제공하며, 향후 이러한 인터페이스를 더욱 미세 조정한 후 구독 체인의 특정 데이터 및 계정 증명을 지원할 것입니다. 이를 통해 라이트 클라이언트는 전체 노드를 실행하거나 많은 수의 트랜잭션을 처리하지 않고 향후 최소한의 검증 가능한 데이터만 유지할 수 있습니다.

7. 간소화된 일괄 처리 및 병렬 트랜잭션 처리

처리량을 최대화하고 동시성을 높이고 엔지니어링 복잡성을 줄이기 위해 Aptos 블록체인의 트랜잭션 처리 프로세스는 여러 단계로 나뉩니다. 각 단계는 완전히 독립적이며 최신 슈퍼스칼라 프로세서 아키텍처와 유사하게 독립적으로 병렬화할 수 있습니다. 이는 상당한 성능 이점을 제공할 뿐만 아니라 Aptos 블록체인이 새로운 유효성 검사기-클라이언트 상호 작용 모델을 제공할 수 있도록 합니다. 예를 들어:

• 보유 트랜잭션 배치에 지정된 트랜잭션이 포함되면 클라이언트에게 알림이 전송됩니다. 보류 중이고 유효한 트랜잭션은 일반적으로 즉시 커밋됩니다.
• 예약된 트랜잭션 배치가 주문되면 클라이언트에게 알림이 전송됩니다. 따라서 실행할 트랜잭션의 결과를 결정하는 지연을 줄이기 위해 클라이언트는 원격 유효성 검사 노드가 실행을 완료하기를 기다리는 대신 로컬에서 트랜잭션을 실행할 수 있습니다.
• 클라이언트는 검증자가 인증된 트랜잭션을 실행할 때까지 기다린 다음 완료된 트랜잭션 상태를 동기화하도록 선택할 수 있습니다(섹션 8 참조).

Aptos 모듈 설계는 개발 속도를 높이고 릴리스 주기를 단축하는 데 도움이 되며 개발자는 전체 시스템 대신 개별 모듈을 최적화할 수 있습니다. 마찬가지로 모듈식 설계는 검증자를 확장할 수 있는 구조화된 경로를 제공하여 검증자가 여러 시스템의 컴퓨팅, 네트워크 및 스토리지 리소스를 활용할 수 있도록 합니다. 그림 4는 트랜잭션 처리 라이프사이클의 다양한 처리 단계를 보여줍니다.

7.1 일괄 처리

일괄 처리는 Aptos 처리의 모든 단계에서 중요한 효율성 최적화입니다. 트랜잭션을 전파할 때 유효성 검사기는 트랜잭션을 배치로 그룹화하고 합의 단계에서 배치는 블록으로 병합됩니다. 실행, 저장 및 원장 인증 단계는 또한 배치 작업으로 재정렬, 작업 감소(예: 이중 계산 또는 서명 확인) 및 병렬 실행의 기회를 제공합니다.

트랜잭션을 일괄 처리하면 트랜잭션을 전파하기 전에 일괄 처리가 채워질 때까지 200ms를 기다리는 것과 같이 약간의 지연이 발생할 수 있습니다. 그러나 일괄 처리를 위한 최대 대기 시간과 최대 일괄 처리 크기를 구성할 수 있으므로 분산형 네트워크가 대기 시간과 효율성을 자동으로 최적화할 수 있습니다. 일괄 처리를 사용하면 악의적인 클라이언트의 서비스 거부(DoS) 공격을 피하면서 트랜잭션의 수수료 시장 우선 순위를 효율적으로 지정할 수 있습니다.

7.2 지속적인 트랜잭션 브로드캐스트

Narwhal & Tusk [9]의 주요 관점에 따르면 Aptos의 트랜잭션 전파와 합의는 분리되어 있습니다. 유효성 검사기는 사용 가능한 모든 네트워크 리소스를 활용하면서 지속적으로 트랜잭션 배치를 서로 전송합니다. 검증자 v에 의해 배포된 각 배치는 지속되고 서명된 배치 다이제스트는 v로 다시 전송됩니다. 배치 다이제스트의 모든 2f + 1 스테이크 가중 서명은 섹션 7.3에 정의된 합의 요구 사항에 따라 PoAv(가용성 증명)를 형성합니다. 이러한 증명(PoAv)은 적어도 f+1개의 가중 정직한 검증자가 배치를 저장했음을 보장하므로 모든 정직한 검증자는 실행 전에 배치를 검색할 수 있습니다.

보류 중인 무제한 트랜잭션은 DoS 공격을 일으켜 유효성 검사기 노드의 저장 공간이 부족해지고 충돌이 발생할 수 있습니다. 이를 방지하기 위해 트랜잭션의 각 배치에는 연관된 타임스탬프가 있습니다. 배치의 타임스탬프는 유효성 검사기의 효율적인 가비지 수집을 허용합니다. 또한 단일 유효성 검사기 노드에 대한 할당량 메커니즘은 가장 극단적인 경우(예: 잠재적인 비잔틴 공격)에도 공간이 고갈되지 않도록 설계되었습니다. 동시에 배치의 데이터 양에는 제한이 있으며 Aptos는 영구 저장소의 데이터 크기를 확인합니다. 마지막으로 트랜잭션 캐시 및 중복 트랜잭션 데이터 정리를 위한 일부 최적화를 통해 스토리지 비용이 절감될 뿐만 아니라 병렬 실행 엔진의 고성능 통합이 보장됩니다.

7.3 블록 메타데이터 정렬

느린 합의 속도가 블록체인의 높은 처리량과 낮은 대기 시간의 주요 병목 현상이라는 일반적인 오해가 있습니다. Aptos 블록체인의 주요 혁신 중 하나는 트랜잭션 전파, 트랜잭션 실행/저장 및 원장 인증과 같은 합의 단계에서 비프로토콜 관련 작업을 분리하는 것입니다. 컨센서스 단계에서 트랜잭션 전파를 분리함으로써 매우 낮은 대역폭(블록 메타데이터 및 증명만)에서 주문을 수행할 수 있으므로 높은 트랜잭션 처리량과 최소 대기 시간을 얻을 수 있습니다.

오늘날 Aptos 블록체인은 낙관적으로 반응하는 BFT 합의 프로토콜인 최신 버전의 DiemBFTv4[10]를 사용합니다. 일반적으로 합의에는 두 번의 네트워크 왕복만 필요하며(전체 네트워크 왕복 시간은 일반적으로 300밀리초 미만) 비정상적인 유효성 검사기는 리더 평판 메커니즘을 통해 동적으로 조정됩니다[11]. 온체인 리더 평판 메커니즘은 "기간" 동안 블록을 성공적으로 제출한 검증인의 평판을 높이고 참여하지 않은 검증인을 강등시킵니다. 이 새로운 메커니즘은 분산 시스템의 성능을 크게 향상시키고 노드에 적절한 인센티브를 제공하며 비활성 유효성 검사기가 처리량 및 대기 시간에 미치는 영향을 최소화합니다.

DiemBFTv4는 부분 동기화 하에서 활성을 보장하고 비동기 하에서 보안을 보장합니다.총 검증인 지분이 3f + 1보다 크거나 같을 때 최대 f 지분 가중치 잘못된 검증인이 있을 수 있습니다. 2019년부터 DiemBFTv4는 수십 개의 노드 운영자와 다중 지갑 생태계를 여러 번 반복하여 광범위한 테스트를 거쳤습니다. 또한 최근 연구(예: Bullshark[12])와 블록 메타데이터 순서 및 최종성을 결정하기 위해 블록 기록 및 관련 통신에 의존하는 기타 프로토콜을 실험하고 있습니다.

합의 블록 및 제안 타임스탬프는 그림 5와 같이 리더가 제안하고 다른 검증자가 동의합니다. 각 합의 블록에는 배치의 메타데이터와 증명만 포함되어 있다는 점에 유의해야 합니다. 합의 블록에는 실제 트랜잭션이 필요하지 않습니다. PoAV는 블록 메타데이터 주문 후 실행 단계에서 트랜잭션 배치를 사용할 수 있도록 보장하기 때문입니다(섹션 7.2 참조). 유효성 검사기는 증명이 검증되고 블록 메타데이터 기준이 충족된 후 리더의 제안에 투표할 수 있습니다(예: 제안 타임스탬프는 블록 만료 시간을 초과할 수 없음).

7.3.1 블록체인 시간

Aptos 블록체인은 각각의 제안된 블록과 해당 블록 내의 모든 해당 트랜잭션에 대략적이고 합의된 물리적 타임스탬프를 할당합니다. 이 타임스탬프는 여러 중요한 사용 사례를 지원합니다. 예를 들어:

• 스마트 계약의 시간 관련 논리. 예를 들어 개발자가 경매에 대한 모든 입찰이 목요일 정오 12시까지 접수되어야 한다고 코딩하려고 합니다.
• 오라클이 온체인 데이터를 게시함에 따라 이벤트를 상호 연관시키고 실제 데이터의 대기 시간을 처리하려면 정확하고 신뢰할 수 있는 온체인 타임스탬프가 필요합니다.
• 고객은 자신이 블록체인에서 얼마나 최신 상태인지 알 수 있습니다. 보안상의 이유로 부실 데이터 및 원격 공격을 방지하기 위해 클라이언트는 계정 상태가 업데이트된 시점의 고정밀 타임스탬프에 액세스할 수 있어야 합니다.
• 신뢰할 수 있는 타임스탬프로 블록체인을 감사하면 법적으로 집행된 지출이 예상대로 이루어지도록 하는 등 오프체인 이벤트에 대한 강력한 상관관계를 제공할 수 있습니다.
• 트랜잭션 만료는 가장 최근 커밋 타임스탬프를 기반으로 합니다. 클라이언트 측 트랜잭션에 대한 추가 보호로 클라이언트는 섹션 6.1에 설명된 대로 트랜잭션의 만료 시간을 선택할 수 있습니다.

Aptos 블록체인은 블록 내 모든 트랜잭션의 타임스탬프에 대해 다음과 같은 보증을 제공합니다.

• 블록체인에서 타임스탬프는 단조롭게 증가합니다. 블록 B1을 가정합니다.
• 트랜잭션 블록의 타임스탬프 T가 확인되면 적어도 f + 1명의 정직한 검증자는 시점 T가 경과했다고 믿습니다. 정직한 검증자는 자신의 시계 ≥ 블록 타임스탬프 T인 경우에만 블록에 투표할 수 있습니다. 섹션 7.2를 참조하십시오.
• 트랜잭션 블록이 타임스탬프 T에 특정 수의 합의 서명을 가지고 있는 경우 정직한 검증자는 다음을 수행합니다.

가장 최근 타임스탬프는 커밋된 각 블록에서 업데이트되며 해당 블록의 모든 트랜잭션에 대한 타임스탬프로 사용됩니다. 네트워크가 동기화되면 모든 네트워크 왕복에 대해 트랜잭션 블록이 커밋되어 빠른 업데이트와 매우 안정적인 타이밍을 제공합니다. 원하는 경우 트랜잭션 블록 내에서 세분화된 순서를 결정할 수 있습니다.

7.4 병렬 트랜잭션 실행

합의 블록 메타데이터가 정렬되면 모든 유효성 검사기 노드, 전체 노드 또는 클라이언트가 트랜잭션을 실행할 수 있습니다. 최소 2f+1개의 가중 검증자가 제안된 배치에 대해 검증 가능하게 진행 중인 트랜잭션을 가지고 있습니다. 트랜잭션 전파는 지속적이므로 다른 정직한 유효성 검사기는 시간이 지남에 따라 트랜잭션 일괄 처리를 받습니다. 정직한 유효성 검사기 노드가 실행 단계에 도달할 때까지 주문된 트랜잭션 배치를 받지 못한 경우 최소 f+1개의 지분 가중 유효성 검사기가 있는 것으로 알려진 2f+1개의 지분 가중 유효성 검사기에서 다운로드할 수 있습니다. 지분 가중 PoAV 서명자의 절반 이상이 정직합니다.

블록체인의 중요한 목표는 가능한 한 많은 병렬 처리를 달성하는 것입니다. 앱토스 블록체인은 데이터 모델과 실행 엔진이라는 두 가지 측면에서 출발합니다.

7.4.1 병렬 데이터 모델

Move 언어 데이터 모델은 기본적으로 데이터 및 모듈의 전역 주소 지정을 지원합니다. 겹치지 않고 충돌하는 데이터 및 계정이 있는 트랜잭션을 병렬로 실행할 수 있습니다. Aptos에서 사용되는 파이프라인 설계를 고려할 때 트랜잭션의 재정렬은 충돌을 줄이고 동시성을 향상시킬 수 있습니다.

트랜잭션이 동일한 온체인 값 세트를 수정하더라도 대부분의 트랜잭션은 여전히 병렬로 실행될 수 있습니다. Aptos 블록체인은 수정된 계정 상태가 아닌 계정 상태에 대한 수정을 설명하는 델타 쓰기라는 새로운 개념을 도입합니다(예: 단순히 최종 값을 결정하는 대신 정수를 증가). 모든 트랜잭션 처리는 병렬로 수행할 수 있으며 충돌하는 값에 대한 델타 쓰기는 올바른 순서로 수행되어 결정론적 결과를 보장합니다.

시간이 지남에 따라 Aptos 블록체인은 동시성을 높이고(예: 읽기/쓰기 힌트 활용) 개발자 경험을 개선하여 개발자가 온체인 값을 보다 자연스럽게 생성, 수정 및 결합할 수 있도록 하여 데이터 모델을 계속 향상시킬 것입니다. Move는 언어 수준 및 플랫폼별 기능 향상을 위한 유연성을 제공합니다.

7.4.2 병렬 실행 엔진

Block-STM 병렬 실행 엔진은 특정 순서에서 최대 병렬성을 달성하기 위해 낙관적 동시성 제어를 수행하면서 순서가 지정된 트랜잭션의 충돌을 감지하고 관리합니다[13].

배치 트랜잭션은 낙관적 잠금을 사용하여 병렬화되고 실행 후 확인됩니다. 유효성 검사에 실패하면 다시 실행됩니다. Block-STM은 다중 버전 데이터 구조를 사용하여 쓰기-쓰기 충돌을 방지합니다. 동일한 위치에 대한 모든 쓰기는 ID와 낙관적으로 재시도된 횟수가 포함된 버전과 함께 저장됩니다. 트랜잭션 tx가 메모리 데이터를 읽을 때 미리 설정된 순서대로 다중 버전 데이터 구조에서 tx 이전에 나타나는 블록 높이가 가장 높은 트랜잭션을 가져와서 트랜잭션 값과 관련 버전을 씁니다.

Block-STM은 Aptos 블록체인에 통합되었습니다. Block-STM의 성능 잠재력을 이해하기 위해 우리는 의미 있는(사소하지 않은) 점대점 이동 트랜잭션(예: 8회 읽기 및 5회 쓰기)과 함께 메모리 내 데이터베이스를 사용합니다. ) 독립 실행형 실행 전용(엔드 투 엔드 아님) 벤치마크. 그림 6은 Block-STM의 실행 결과를 보여준다. 각 블록에는 10,000개의 트랜잭션이 포함되며 계정 수에 따라 충돌 및 분쟁의 정도가 결정됩니다.

경쟁이 낮을 때 Block-STM의 TPS는 32스레드 선형 실행의 16배이며, 경쟁이 높을 때 Block-STM의 TPS도 8배 증가합니다. 다른 블록체인 병렬 실행 엔진과 달리 Block-STM은 동적이고 투명하게(사용자 프롬프트 없이) 모든 워크로드의 본질적인 병렬성을 캡처할 수 있습니다. BlockSTM은 읽거나 쓸 데이터의 위치에 대한 사전 지식이 필요한 병렬 실행 환경보다 더 복잡한 트랜잭션을 동시에 지원할 수 있습니다. 이 속성은 더 적지만 더 효율적인 트랜잭션을 생성하고 비용을 절감하며 사용자에게 더 짧은 대기 시간을 제공합니다. 더 중요한 것은 사물을 여러 개의 작은 트랜잭션으로 분할하면 트랜잭션의 원자성이 깨집니다(모든 작업은 분할할 수 없으며 모든 작업이 성공하거나 모두 실패합니다). 표현적인 트랜잭션 시맨틱과 Block-STM의 병렬 실행을 결합하면 개발자가 두 세계의 장점을 모두 누릴 수 있습니다.

블록 메타데이터 순서 지정 단계는 병렬 실행 단계 동안 트랜잭션 재정렬을 배제하지 않습니다. 병렬 실행을 위한 동시성 성능을 최적화하기 위해 블록 간에 트랜잭션을 재정렬할 수 있습니다. 유일한 요구 사항은 모든 정직한 유효성 검사기의 재정렬이 되돌릴 수 없어야 한다는 것입니다. 병렬 실행을 최적화하고 재정렬에 무작위화를 추가하면 성능을 개선할 수 있고 잠재적으로 동기가 있는 유효성 검사기 트랜잭션에 의해 채굴자 추출 가능 가치(MEV) 기술이 재정렬되는 것을 방지할 수 있습니다. 이 파이프라인 설계에서 "order-then-reveal"(Order-then-reveal)의 안티 MEV 전략도 추가할 수 있습니다.

Block-STM과 트랜잭션 재정렬은 실행 동시성을 높이는 상호 보완적인 기술입니다. 추가 동시성을 위해 트랜잭션 읽기/쓰기 액세스 힌트와 결합할 수 있습니다.

7.5 대량 저장

병렬 실행 단계의 결과는 그룹에 있는 모든 트랜잭션의 쓰기 세트입니다. 이러한 쓰기 세트는 최대 실행 속도를 위해 메모리에 저장한 다음 실행할 다음 블록 또는 블록 세트의 캐시로 사용할 수 있습니다. 겹치는 쓰기는 안정적인 저장소에 한 번만 쓰면 됩니다. 유효성 검사기가 메모리 내 쓰기 집합을 저장하기 전에 실패하면 블록 메타데이터 순서 지정 단계에서 병렬 실행을 다시 시작할 수 있습니다. 병렬 실행 단계에서 쓰기 세트의 대량 스토리지를 분리하면 병렬 실행이 효율적으로 실행될 수 있습니다. 요약하면 쓰기 세트 일괄 처리는 스토리지 작업 수를 줄이고 더 효율적이고 더 큰 I/O 작업을 활용합니다.

쓰기 세트 캐시용으로 예약된 메모리 양은 시스템별로 수동으로 구성할 수 있으며 자연스러운 배압 메커니즘을 제공합니다. 특정 I/O 및 메모리 환경에 대해 조정이 필요한 경우 배치 처리의 세분성은 병렬 실행 블록의 세분성과 다를 수 있습니다.

7.6 원장 인증

이 시점(일괄 저장)에서 파이프라인의 각 개별 유효성 검사기는 커밋된 트랜잭션 블록에 대한 새 상태를 계산했습니다. 그러나 인증된 라이트 클라이언트와 상태 동기화를 효율적으로 지원하기 위해 Aptos 블록체인은 원장 기록 및 원장 상태에 대한 원장 인증을 구현합니다. Aptos 블록체인의 주요 차이점은 원장 인증이 트랜잭션 처리의 중요한 경로에 있지 않으며 필요한 경우 완전히 직접 실행할 수도 있다는 것입니다.

7.6.1 계정 내역 확인

유효성 검사기는 실행 출력과 함께 트랜잭션을 전역적으로 인증된 원장 데이터 구조에 추가합니다. 트랜잭션 출력의 일부는 Move에서 액세스할 수 있는 전역 상태에 대한 변경 사항을 포함하여 상태 쓰기 세트입니다. 이 데이터 구조의 짧은 유효성 검사기는 새로 실행된 트랜잭션 배치를 포함하는 원장 기록에 대한 구속력 있는 약속입니다. 트랜잭션 실행과 유사하게 이 데이터 구조의 생성은 결정적입니다.

각 검증자는 짧은 인증자를 결과 데이터베이스의 새 버전에 서명합니다. 유효성 검사기는 가장 최근에 서명된 짧은 유효성 검사기 세트를 서로 공유하고, 쿼럼 서명된 짧은 인증자를 집합적으로 집계하며, 가장 최근의 쿼럼 서명된 짧은 유효성 검사기도 서로 공유합니다.

BFT 프로토콜의 속성에 따라 이 집단 서명을 사용하여 클라이언트는 데이터베이스 버전이 완전하고 유효하며 되돌릴 수 없는 원장 기록을 나타낸다고 신뢰할 수 있습니다. 클라이언트는 모든 유효성 검사기(또는 전체 노드와 같은 데이터베이스의 타사 복사본)를 쿼리하여 데이터베이스 값을 읽고 유효성 검사기와 필요한 데이터 증명을 사용하여 결과를 확인할 수 있습니다.

7.6.2 주기적 상태 인증

Move 언어로 액세스할 수 있는 전체 글로벌 상태는 원장의 기록 요약과 유사하게 기록의 어느 시점에서든 짧은 유효성 검사기로 집계할 수 있습니다. 부록 전용 원장 기록과 달리 전역 상태의 임의 액세스 특성으로 인해 이 인증을 유지하는 데 비용이 많이 듭니다. 그러나 대규모 배치로 데이터 구조를 업데이트할 때 업데이트를 병렬로 계산할 수 있고 각 개별 상태 값이 변경될 때 업데이트해야 하는 부분 간의 중복을 활용할 수도 있습니다. Aptos 블록체인은 의식적으로 글로벌 상태의 주기적인 유효성 검사를 사용하여 중복 공유 업데이트를 줄입니다.

결정적이고 구성 가능한 기간 동안 네트워크는 상태 조합 지점 트랜잭션을 게시하며 그 결과 부분에는 전역 상태 인증자가 포함됩니다. 이 버전을 상태 체크포인트라고 합니다. 두 데이터 정렬 지점 사이의 간격이 클수록 각 트랜잭션에서 상태 인증 데이터 구조를 업데이트하는 상각 비용이 낮아집니다.

상태 데이터 정렬 지점을 통해 사람들은 모든 전역 상태를 저장하지 않고도 무신뢰 방식으로 모든 상태 값을 읽을 수 있습니다. 이 기능은 증분 상태 동기화, 유효성 검사기 노드 전체의 샤딩된 스토리지, 상태 비저장 유효성 검사기 노드 및 스토리지 제약이 있는 라이트 클라이언트와 같은 애플리케이션에 적합합니다.

그러나 상태 체크포인트는 주기적이므로 원장 상태의 특정 버전에 대한 증명을 얻으려면 누락된 상태에 대해 추가 트랜잭션을 번갈아 실행하거나 검증된 원장 기록에서 이를 포함하는 증명을 얻어야 합니다.

상태 체크포인트는 원장 기록의 특정 트랜잭션 버전과 연결되므로 섹션 7에서 언급한 트랜잭션 일괄 처리와 관련된 타임스탬프에 연결됩니다. 타임스탬프를 사용하면 라이트 클라이언트가 입증된 상태 값의 적시성을 이해할 수 있습니다. 타임스탬프가 없는 경우 라이트 클라이언트 증명은 오래 전부터 이전 상태의 유효성만 보장할 수 있으므로 연관성에 대한 보장은 거의 제공되지 않습니다. 또한 상태 증명의 타임스탬프는 기록 액세스 및 감사를 추적하는 데 필요합니다(예: 토큰 보유량의 시간당 평균 토큰 잔액 계산).

상태 체크포인트는 이전 상태 체크포인트와 트랜잭션 결과의 후속 상태 변경을 기반으로 생성될 수 있습니다. 따라서 안정적인 저장소에 대한 지속 상태 체크포인트는 트랜잭션 처리의 주요 경로에 있을 필요가 없습니다. 또한 상태 확인 포인트를 유지하는 것은 유익한 일괄 처리 효과도 있습니다. 가장 최근 상태 체크포인트(또는 그 사이의 델타)를 메모리에 캐싱하고 주기적인 상태 체크포인트만 안정적인 스토리지에 덤핑하면 스토리지 대역폭 소비를 크게 줄일 수 있습니다. 체크포인트를 유지하는 방법의 선택은 검증된 데이터 구조의 계산에 영향을 미치지 않습니다. 따라서 각 노드에 대한 선택입니다. 노드 운영자는 메모리 용량과 스토리지 대역폭 간에 적절한 절충안을 만들 수 있습니다.

8. 상태 동기화

Aptos 블록체인은 생태계의 모든 참여자에게 높은 처리량, 낮은 대기 시간 시스템을 제공하는 것을 목표로 합니다. 따라서 블록체인은 블록체인 데이터를 라이트 클라이언트, 풀 노드 및 검증 노드에 전파, 검증 및 유지하기 위한 효율적인 상태 동기화 프로토콜을 제공해야 합니다[14]. 또한 사용자의 다양한 하드웨어 리소스를 고려하여 동기화 프로토콜은 네트워크에 존재하는 리소스 제한 및 차이점과도 호환되어야 합니다. 예를 들어 아카이브 풀 노드가 전체 블록체인 상태와 기록을 확인하고 저장할 수 있도록 허용하는 동시에 라이트 클라이언트가 블록체인 상태의 작은 부분에만 효율적으로 액세스할 수 있도록 해야 합니다.

이 기능을 달성하기 위해 Aptos 블록체인은 유효성 검사기, 전체 노드 및 기타 동기화 장치(섹션 7.6.1 참조)가 제공하는 인증된 원장 기록 및 상태 증명을 활용하여 유연하고 구성 가능한 동기화 프로토콜을 구현합니다. 특히 네트워크 참가자는 자신의 사용 사례와 요구 사항을 최적화하기 위해 다양한 동기화 전략을 선택할 수 있습니다.

예를 들어, Aptos는 전체 동기화 전략, 과거 기록을 무시하고 앵커를 사용하여 최신 블록체인 상태만 동기화하는 전략을 포함하여 전체 노드에 대한 다양한 동기화 전략을 제공합니다. Aptos는 특정 계정이나 데이터를 동기화할 수 있는 부분 동기화 전략, 계정 잔액을 확인할 수 있는 데이터 확인 전략 등 라이트 클라이언트를 위한 다양한 동기화 전략을 제공합니다. 모든 경우에 Aptos는 참가자가 구성 구성을 통해 특정 수량 및 버전의 데이터를 획득, 처리 및 저장할 수 있도록 합니다.

이 유연하고 구성 가능한 상태 동기화 프로토콜을 통해 Aptos는 다양한 고객의 요구를 충족하고 향후 보다 발전되고 효율적인 동기화 전략을 제공할 수 있습니다.

9. 커뮤니티 거버넌스

Aptos 블록체인은 광범위하고 다양한 커뮤니티에서 소유, 운영 및 관리합니다. 기본 Aptos 토큰은 트랜잭션 및 네트워크 수수료, 프로토콜 업그레이드 및 온체인/오프체인 프로세스에 대한 거버넌스 투표는 물론 PoS(지분 증명) 모델을 통해 블록체인을 보호하는 데 사용됩니다. Aptos 토큰의 구체적인 경제 모델은 추후 공개될 예정입니다.

9.1 거래 및 네트워크 수수료

모든 Aptos 트랜잭션에는 수수료 단위 가격(Aptos 토큰에 지정됨)이 있어 검증자가 네트워크에서 가장 가치가 높은 트랜잭션의 우선 순위를 지정할 수 있습니다. 또한 파이프라인 모델의 각 단계에서 가치가 낮은 트랜잭션을 포기할 수 있는 여러 기회가 있습니다(블록체인이 최대 시스템 용량에서 여전히 효율적으로 실행될 수 있도록 가능한 한). 시간이 지남에 따라 수수료의 배포는 Aptos 블록체인 사용 비용이 하드웨어 배포, 유지 관리 및 노드 운영의 실제 비용에 비례하도록 합니다. 또한 개발자가 설계한 애플리케이션은 서로 다른 비용에 따라 컴퓨팅, 스토리지 및 네트워킹 간에 균형을 이룰 수 있습니다.

9.2 네트워크 거버넌스

Aptos 블록체인의 모든 주요 기능 최적화 및 반복은 제안, 구현, 테스트 및 배포를 포함한 여러 단계를 거칩니다. 이 구조는 이해 당사자 및 이해 관계자가 피드백을 제공하고 우려 사항을 공유하고 제안할 수 있는 기회를 제공합니다. 마지막 단계인 배포는 일반적으로 두 단계로 수행됩니다. 첫째, 새로운 기능이 포함된 소프트웨어 버전이 각 노드에 배포되고 둘째, 예를 들어 기능 플래그 또는 온체인 구성 변수를 통해 기능이 켜집니다.

노드 운영자가 배포하는 모든 소프트웨어는 새 소프트웨어가 지원되는 버전과 상호 운용될 수 있도록 이전 버전과 호환되어야 합니다. 새 소프트웨어 버전을 배포하는 프로세스는 다른 시간대의 운영자와 외부 문제를 고려하여 며칠이 걸릴 수 있습니다. 충분한 수의 노드가 업그레이드되면 사전 합의된 블록 높이 또는 에포크 스위치와 같은 동기화 지점에 의해 새로운 기능의 활성화가 트리거될 수 있습니다. 긴급 상황(예: 다운타임을 피할 수 없는 경우)에서는 노드 운영자가 수동 및 강제 변경을 통해 재시작을 활성화할 수 있으며 최악의 경우 네트워크의 하드 포크로 활성화할 수 있습니다.

다른 블록체인과 달리 Aptos 블록체인은 구성을 온체인으로 인코딩합니다. 각 유효성 검사기는 블록체인의 현재 상태와 동기화할 수 있으며 현재 온체인 값을 기반으로 올바른 구성(예: 합의 프로토콜 및 Aptos 프레임워크 버전)을 자동으로 선택할 수 있습니다. 이 기능을 기반으로 Aptos 블록체인의 업그레이드는 매끄럽고 즉각적입니다.

활성화 프로세스 중에 유연성과 구성 가능성을 활성화하기 위해 Aptos 블록체인은 토큰 보유자가 스테이킹된 토큰의 가중치에 따라 투표할 수 있는 온체인 거버넌스를 지원합니다. 온체인 투표 프로토콜은 공개적이고 검증 가능하며 즉각적일 수 있습니다. 온체인 거버넌스는 또한 소프트웨어 배포 없이 논바이너리 결과를 가능하게 합니다. 예를 들어, 온체인 리더 선출 프로토콜 매개변수는 온체인 거버넌스를 통해 수정할 수 있는 반면, 사전에 알려진 동기화 지점은 모든 변경 사항을 미리 알아야 하기 때문에 동적 수정을 처리할 수 없습니다.

온체인 거버넌스는 시간이 지남에 따라 업그레이드 관리 프로세스 전반에 걸쳐 배포될 수 있습니다. 예를 들어:

1. 토큰 보유자는 새로운 양자 저항 서명 체계로 전환하기 위해 온체인에서 투표합니다.

2. 개발자는 새 서명 계획을 구현 및 확인하고 새 소프트웨어 버전을 생성합니다.

3. 유효성 검사기는 소프트웨어를 최신 버전으로 업그레이드합니다.

4. 토큰 보유자는 새로운 서명 체계를 활성화하기 위해 온체인에서 투표하고 온체인 구성이 업데이트되며 변경 사항이 적용됩니다.

오픈 소스 프로젝트인 Aptos 블록체인의 거버넌스는 강력한 커뮤니티 피드백과 온체인 거버넌스에 크게 의존합니다. 경우에 따라 오프 체인 업그레이드를 활성화해야 할 수도 있지만 시간이 지남에 따라 최소화됩니다.

9.3 지분 증명 서약 합의

Aptos 블록체인에서 트랜잭션 유효성 검사에 참여하려면 유효성 검사기가 Aptos 토큰의 최소 지분을 가지고 있어야 합니다. 트랜잭션 전파, 투표 가중치 및 블록 메타데이터 순서 지정에서 리더 선출 프로세스 중에 지분 금액은 2f + 1 지분 가중치 PoAv에 비례하여 영향을 미칩니다. 유효성 검사기는 자신과 각 스테이커 간의 보상 분배를 결정합니다. 스테이커는 미리 합의된 보상 분배를 위해 토큰을 스테이킹할 검증자를 원하는 수만큼 선택할 수 있습니다. 각 에포크가 끝날 때 검증자와 해당 스테이커는 관련 온체인 이동 모듈을 통해 보상을 받습니다.

충분한 담보가 있는 검증인은 누구나 앱토스 블록체인에 자유롭게 가입할 수 있습니다. 최소 요구 스테이크 값을 포함한 모든 매개변수는 섹션 9.2에 설명된 온체인 인에이블러로 설정할 수 있습니다.

10. 성능

섹션 7에서 설명한 것처럼 Aptos 블록체인은 병렬, 배치 최적화 및 모듈식 트랜잭션 처리 파이프라인을 통해 최적의 처리량과 하드웨어 효율성을 달성할 수 있습니다. 합의 업그레이드, 지연된 쓰기, 트랜잭션 힌트 및 중요 경로 캐싱과 같은 추가 성능 이니셔티브는 시간이 지남에 따라 계속해서 처리량을 늘리고 효율성을 개선할 것입니다.

오늘날 블록체인 처리량은 종종 초당 트랜잭션으로 측정됩니다. 그러나 이것은 다양한 수준의 트랜잭션과 인프라 비용 및 복잡성을 고려할 때 시스템을 비교하는 부정확한 방법입니다. 완결성에 대한 커밋이 다른 실험에서 다르게 시작하고 끝나기 때문에 트랜잭션 지연에도 결함이 있습니다.

또한 일부 시스템에서는 트랜잭션 입력 및 출력에 대한 사전 지식이 필요하며 논리적 트랜잭션을 더 작고 덜 복잡한 트랜잭션으로 강제로 분할합니다. 트랜잭션을 분할하면 사용자 경험이 저하되고 대기 시간과 처리량에 인위적으로 영향을 미쳐 개발자가 달성하려는 것을 무시합니다. 대조적으로 Aptos의 접근 방식은 개발자에게 합성 트랜잭션이 아닌 실제 사용 사례에 대해 처리량과 대기 시간을 구축하고 측정할 수 있는 무제한의 자유를 제공합니다.

Aptos 블록체인은 계속해서 개별 유효성 검사기의 성능을 최적화하고 네트워크에 더 많은 유효성 검사기를 추가하는 확장 기술을 실험할 것입니다. 두 방향 모두에 분명한 장단점이 있습니다. 병렬 실행이 가능한 모든 블록체인은 더 강력한 하드웨어를 요구하거나 각 유효성 검사기를 별도의 기계 클러스터로 구성하여 더 큰 동시성을 지원할 수 있습니다. 그러나 글로벌 검증인의 수에는 실질적인 한계가 있으며 이는 검증인 운영자의 비용과 복잡성에 해당합니다. 클라우드 서비스에서 서버리스 데이터베이스의 증가와 인기는 이러한 유형의 복잡한 분산 시스템을 효과적으로 배포하고 유지 관리할 수 있는 엔터티가 거의 없음을 보여줍니다.

10.1 동종 상태 샤딩

처음에 Aptos 블록체인은 단일 원장 상태로 시작됩니다. 시간이 지남에 따라 Aptos 네트워크는 여전히 분산된 상태를 유지하면서 수평적 확장성에 대한 고유한 접근 방식을 취할 것입니다. 이는 각각 동종 API를 제공하고 샤딩을 주요 개념으로 사용하는 다중 샤딩 원장의 상태를 통해 달성됩니다. Aptos 토큰은 모든 샤드의 거래 수수료, 예금 및 거버넌스에 사용됩니다.

동종 브리지를 통해 샤드 간에 데이터를 전송할 수 있습니다. 사용자와 개발자는 필요에 따라 자체 샤딩 체계를 선택할 수 있습니다. 예를 들어 개발자는 새 샤드를 제안하거나 기존 샤드 내에서 사용자를 그룹화하여 샤드 내에서 높은 연결성을 달성할 수 있습니다. 또한 샤드는 시스템 특성이 다를 수 있습니다. 하나의 샤드는 SSD 컴퓨팅에 최적화할 수 있고 다른 샤드는 저성능 대용량 스토리지에 최적화할 수 있습니다. 서로 다른 샤드 간에 하드웨어 유연성을 제공함으로써 개발자는 애플리케이션의 시스템 리소스 활용을 극대화할 수 있습니다.

요약하면 동종 상태 샤딩은 수평적 처리량 확장 가능성을 제공하고 개발자가 샤드 전체에서 단일 공통 상태로 프로그래밍할 수 있도록 하며 지갑이 사용자를 위해 샤드 데이터를 쉽게 통합할 수 있도록 합니다. 이는 통합 Move 스마트 계약 플랫폼의 단순성과 결합하여 상당한 성능 이점을 제공합니다.

참조

1. "앱토스 코어," 2022.
   온라인 설명서. 이용 가능: https://github.com/aptos-labs/aptos-core
   
2. "이동", 2022.
   온라인 설명서. 사용 가능: https://github.com/move-language/move
   
3. Matsuoka, C. Dixon, E. Lazzarin 및 R. Hackett. (2022) 2022년 암호화 상태 보고서 발표. 온라인 설명서. 이용 가능: https://a16z.com/tag/state-crypto-2022/
4. Amsden, R. Arora, S. Bano, M. Baudet, S. Blackshear, A. Bothra, G. Cabrera, C. Catalini, K. Chalkias, Cheng, A. Ching, A. Chursin, G. Danezis, GD Giacomo , DL Dill, H. Ding, N. Doudchenko, Gao, Z. Gao, F. Garillot, M. Gorven, P. Hayes, JM Hou, Y. Hu, K. Hurley, K. Lewi, C. Li, Z . Li, Malkhi, S. Margulis, B. Maurer, P. Mohassel, L. de Naurois, V. Nikolaenko, T. Nowacki, O. Orlov, Perelman, A. Pot, B. Proctor, S. Qadeer, Rain, D. Russi, B. Schwab, S. Sezer, A. Sonnino, H. Venter, L. Wei, N. Wernerfelt, B. Williams, Q. Wu, X. Yan, T. Zakian 및 R. Zhou, “천칭자리 블록체인", 2019.
   온라인 설명서. 이용 가능: https://developers.diem.com/papers/the-diem-blockchain/2020-05-26.pdf
   
5. Blackshear, E. Cheng, DL Dill, V. Gao, B. Maurer, T. Nowacki, A. Pott, S. Qadeer, DR Rain, S. Sezer, T. Zakian 및 R. Zhou, "무브: A 더 프로그래밍 가능한 리소스의 언어", 2019.
   [온라인] 이용 가능: https://developers.diem.com/papers/diem-move-a-language-with-programmableresources/2019-06-18.pdf
   
6. Dill, W. Grieskamp, J. Park, S. Qadeer, M. Xu 및 E. Zhong, "Move Validator를 사용한 스마트 계약의 빠르고 안정적인 공식 검증", 구성 및 분석을 위한 도구 및 알고리즘에 게시됨 of Systems, D. Fisman 및 G. Rosu, Eds. Cham: Springer International Publishing, 2022, pp. 183-200.
7. Popper.(2021) 암호를 잃어버리면 백만장자의 비트코인 재산이 잠깁니다.
   온라인 설명서. 이용 가능: https://www.nytimes.com/2021/01/12/technology/bitcoin-passwords-wallets-fortunes.html
   
8. Diem Group, "재구성된 시스템에서 커밋 정보의 상태 동기화 및 확인", 2020.
   온라인 설명서. 이용 가능: https://github.com/aptos-labs/aptoscore/blob/main/documentation/tech-papers/lbft-verification/lbft-verification.pdf
   
9. Danezis, L. Kokoris-Kogias, A. Sonnino 및 A. Spiegelman, "일각 고래와 엄니: dag 기반 mempool 및 효율적인 bft 합의", 컴퓨터 시스템에 관한 17차 유럽 회의 회보, ser. EuroSys' 22. 미국 뉴욕주 뉴욕: 컴퓨팅 기계 협회, 2022년, 34-50페이지.
   온라인 설명서. 이용 가능: https://doi.org/10.1145/3492321.3519594
   
10. Diem Group, "Diembft v4: 일 블록체인의 상태 머신 복제", 2021.
    온라인 설명서. 이용 가능: https://developers.diem.com/papers/diem-consensus-state-machine-replication-in-the-diemblockchain/2021-08-17.pdf
    
11. Cohen, R. Gelashvili, L. Kokoris-Kogias, Z. Li, D. Malkhi, A. Sonnino 및 A. Spiegelman, "당신의 지도자로 알려지십시오", CoR, vol. abs/2110.00960, 2021.
    온라인 설명서. 이용 가능: https://arxiv.org/abs/2110.00960
    
12. Spiegelman, N. Giridharan, A. Sonnino 및 L. Kokoris-Kogias, "Bullshark: A Practical Implementation of the Dag bft protocol," 컴퓨터 및 통신 보안(CCS)에 관한 20차 회의 절차, CCS [22 ]. 미국 캘리포니아주 로스앤젤레스: 컴퓨팅 기계 협회, 2022.
13. Gelashvili, A. Spiegelman, Z. Xiang, G. Danezis, Z. Li, Y. Xia, R. Zhou 및 D. Malkhi, “Block-stm: 정렬의 저주를 성능 체인의 축복으로 바꾸어 블록 확장 처형", 2022.
    온라인 설명서. 이용 가능: https://arxiv.org/abs/2203.06871
    
14. Lind, "상태 동기화의 진화: 초당 100,000개 이상의 트랜잭션으로의 경로, 앱토스의 1초 미만 지연 시간", 2022년.
    온라인 설명서. 이용 가능: https://medium.com/aptoslabs/52e25a2c6f10
    

기사 출처: Buidler DAO