텍스트

이 설문조사는 이더리움과 유사한 구현 시스템을 비교하고 트랜잭션의 병렬 실행의 어려움과 가능성을 분석했습니다. 체인 자체는 UTXO 모델이 아닌 계정 모델을 기반으로 설계되었습니다.

첫 번째 레벨 제목

1. FISCO-BCOS와 같은 중국의 많은 얼라이언스 체인은 블록 내 트랜잭션 검증의 병렬 실행을 지원합니다.

2. 공개 체인 프로젝트인 Khipu는 이더리움 프로토콜의 스칼라 구현입니다.

3. Aptos, 퍼블릭 체인 프로젝트, 가상 머신 이동.

첫 번째 레벨 제목

트랜잭션 병렬 실행의 어려움

먼저 기존 트랜잭션 실행 프로세스를 검토해 보겠습니다.

실행 모듈은 블록에서 트랜잭션을 하나씩 꺼내어 하나씩 실행합니다. 실행 과정에서 최신 세계 상태가 수정되며 트랜잭션이 실행된 후 상태가 누적되어 블록 완료 후 최신 세계 상태에 도달합니다. 다음 블록의 실행은 이전 블록 실행 후의 세계 상태에 엄격히 의존하므로 트랜잭션의 전통적인 선형 실행 프로세스는 병렬 실행에 대해 잘 최적화될 수 없습니다.

1. 계정 충돌. 두 개의 스레드가 동시에 주소 계정의 잔액 또는 기타 속성을 처리하는 경우 순차 처리 결과, 즉 세계 상태가 명확한 유한 상태 머신인지 여부와 일치할 수 있습니다.

3. 계약 간 통화 충돌. 원래 컨트랙트 Ar이 먼저 배치되고 컨트랙트 B가 컨트랙트 A가 배치될 때까지 기다려야 컨트랙트 A를 호출할 수 있습니다. 그러나 트랜잭션이 병렬일 때 이러한 순서가 없으며 충돌이 발생합니다.

FISCO-BCOS

첫 번째 레벨 제목

트랜잭션 병렬 체계의 비교

첫 번째 레벨 제목

개요

FISCO-BCOS 2.0은 트랜잭션을 처리하는 과정에서 그래프 구조를 사용하고 DAG 모델을 기반으로 병렬 트랜잭션 실행기(PTE, Parallel Transaction Executor)를 설계한다. PTE는 멀티 코어 프로세서의 장점을 최대한 활용할 수 있으므로 블록의 트랜잭션이 최대한 병렬로 실행될 수 있습니다. 동시에 사용자에게 간단하고 친숙한 프로그래밍 인터페이스를 제공하므로 사용자는 번거로운 병렬 구현 세부 사항에 신경 쓸 필요가 없습니다. 벤치마크 테스트 프로그램의 실험 결과에 따르면 이상적인 조건에서 기존의 직렬 트랜잭션 실행 방식과 비교하여 4코어 프로세서에서 실행되는 PTE는 약 200% ~ 300%의 성능 향상을 달성할 수 있으며 컴퓨팅 향상은 코어 수 정비례로 코어가 많을수록 성능이 높아집니다.

프로그램 세부정보

주기가 없는 유향 그래프를 DAG(Directed Acyclic Graph)라고 합니다. 트랜잭션 묶음에서 각 트랜잭션이 점유하는 상호 배타적 자원을 일정한 방식으로 식별할 수 있으며, 블록 내 트랜잭션 순서와 상호 배타적 자원의 점유 관계에 따라 트랜잭션 종속 DAG 그래프를 구성할 수 있습니다. . 아래 그림과 같이 in-degree가 0인 모든 트랜잭션(종속 사전 주문 작업 없음)은 병렬로 실행될 수 있습니다. 왼쪽의 원래 트랜잭션 목록의 순서를 기반으로 토폴로지 정렬을 하면 오른쪽의 트랜잭션 DAG를 얻을 수 있습니다.

모듈식 아키텍처

• 사용자는 SDK를 통해 직간접적으로 트랜잭션을 시작합니다.

• 그러면 노드 간에 트랜잭션이 동기화되고 패키징 권한을 가진 노드가 실러(Sealer)를 호출하여 (TxPool)에서 일정량의 트랜잭션을 가져와 블록으로 패키징합니다. 이후 노드간 합의를 위해 블록을 합의 유닛(Consensus)으로 보낸다.

• 거래 확인은 합의에 도달하기 전에 수행되어야 하며 여기에서 PTE 작업이 시작됩니다. 아키텍처 다이어그램에서 볼 수 있듯이 PTE는 먼저 블록의 트랜잭션을 순차적으로 읽어 DAG Constructor에 입력합니다. DAG 생성자는 각 트랜잭션의 종속성을 기반으로 모든 트랜잭션을 포함하는 트랜잭션 DAG를 생성합니다. 그런 다음 PTE는 작업자 스레드 풀을 깨우고 여러 스레드를 사용하여 트랜잭션 DAG를 병렬로 실행합니다. 조이너는 작업자 스레드 풀의 모든 스레드가 DAG 실행을 완료할 때까지 기본 스레드를 일시 중단해야 합니다. 이때 Joiner는 각 트랜잭션 쌍의 상태 수정 기록을 기반으로 상태 루트와 수신 루트를 계산하고 실행 결과를 상위 호출자에게 반환합니다.

• 블록 검증이 통과되면 블록이 체인에 업로드됩니다. 트랜잭션이 실행된 후 각 노드의 상태가 일치하면 합의에 도달합니다. 그런 다음 블록은 기본 저장소(Storage)에 기록되고 블록체인에 영구적으로 기록됩니다.

거래 DAG 구축 과정

1. 패키징된 블록에서 해당 블록의 모든 트랜잭션을 꺼냅니다.

2. 트랜잭션 수를 최대 정점 수로 DAG 인스턴스를 초기화합니다.

3. 모든 트랜잭션을 순차적으로 읽습니다. 트랜잭션이 병렬화 가능한 경우 충돌 도메인을 해결하고 이전 트랜잭션이 이 트랜잭션과 충돌하는지 확인합니다. 충돌이 있는 경우 해당 트랜잭션 간에 종속 에지가 구성됩니다. 트랜잭션을 병렬화할 수 없는 경우 이전 트랜잭션이 모두 실행된 후에 실행해야 하는 것으로 간주되므로 이 트랜잭션과 모든 이전 트랜잭션 간에 종속 에지가 설정됩니다.

비고: 모든 종속 에지가 설정된 후에는 병렬로 실행할 수 없으며 순차적으로만 실행할 수 있습니다.

DAG 실행 프로세스

1. 메인 스레드는 먼저 하드웨어 코어 수에 따라 해당 크기의 스레드 그룹을 초기화하고 하드웨어 코어 수를 얻지 못하면 다른 스레드를 생성하지 않습니다.

2. DAG 실행이 완료되지 않은 경우 스레드는 루프를 돌며 DAG의 waitPop 메서드가 진입 수준이 0인 준비 트랜잭션을 꺼내기를 기다립니다. 실행할 트랜잭션이 성공적으로 제거되면 트랜잭션이 실행되고 실행 후 후속 종속 작업의 In-degree가 1 감소합니다. 트랜잭션의 등급이 0으로 감소하면 트랜잭션을 topLevel에 추가합니다. 실패하면 DAG가 실행되었고 스레드가 종료되었음을 의미합니다.

문제와 해결책

1. 동일한 블록에 대해 모든 노드가 실행되고 동일한 상태(3개의 루트 일치)를 갖도록 하는 방법은 무엇입니까?

FISCO BCOS는 상태 루트, 트랜잭션 루트 및 수신 루트 트리플이 동일한지 여부를 확인하여 상태가 일치하는지 여부를 확인하는 방법을 사용합니다. 트랜잭션 루트는 블록 내 모든 트랜잭션을 기반으로 계산된 해시 값으로, 모든 합의 노드에서 처리되는 블록 데이터가 동일하다면 트랜잭션 루트도 동일해야 합니다. 이는 상대적으로 보장하기 쉽기 때문에 트랜잭션이 실행된 후 생성된 상태가 수신 루트와 동일하도록 보장하는 방법에 중점을 둡니다.

서로 다른 CPU 코어에서 병렬로 실행되는 명령의 경우 명령 간의 실행 순서를 미리 예측할 수 없다는 것은 잘 알려져 있습니다. 병렬로 실행되는 트랜잭션의 경우에도 마찬가지입니다. 전통적인 트랜잭션 실행 방식에서는 트랜잭션이 실행될 때마다 상태 루트가 한 번 변경되고 변경된 상태 루트가 트랜잭션 영수증에 기록됩니다. 모든 트랜잭션이 실행된 후 최종 상태 루트는 현재 블록체인의 상태를 나타내며 모든 트랜잭션 영수증을 기반으로 영수증 루트가 계산됩니다.

전통적인 실행 체계에서 상태 루트는 전역 공유 변수와 유사한 역할을 한다는 것을 알 수 있습니다. 트랜잭션이 병렬로 순서 없이 실행되면 상태 루트를 계산하는 전통적인 방법은 분명히 더 이상 적용할 수 없습니다. 이는 트랜잭션의 실행 순서가 일반적으로 다른 시스템에서 다르고 현재 최종 상태 루트의 일관성을 보장할 수 없기 때문입니다. 마찬가지로 수신 루트의 일관성도 보장할 수 없습니다.FISCO BCOS는 트랜잭션이 먼저 병렬로 실행되고 각 트랜잭션의 상태 변경 이력이 기록되며 모든 트랜잭션이 실행된 후 이러한 이력 레코드를 기반으로 상태 루트가 종합적으로 계산됩니다. 이를 통해 트랜잭션이 병렬로 실행되더라도 최종 합의 노드가 여전히 합의에 도달할 수 있습니다.

2. 두 트랜잭션이 종속되어 있는지 확인하는 방법은 무엇입니까?

두 트랜잭션이 종속성이 없지만 종속성이 있다고 판단되면 불필요한 성능 손실이 발생하고, 반대로 두 트랜잭션이 동일한 계정의 상태를 다시 작성하지만 병렬로 실행되면 계정의 최종 상태가 불확실할 수 있습니다. . 그러므로,

종속성 결정은 성능에 영향을 미치고 블록체인이 정상적으로 작동할 수 있는지 여부까지 결정하는 중요한 문제입니다.

단순 이체 트랜잭션에서는 이체의 발신자와 수신자의 주소를 기반으로 두 트랜잭션 사이에 종속성이 있는지 여부를 판단할 수 있습니다.

A→B, C→D, D→E의 3가지 이체 거래를 예로 들어 보겠습니다. 트랜잭션 D→E는 트랜잭션 C→D의 결과에 의존하지만 트랜잭션 A→B는 다른 두 트랜잭션과 연결되지 않으므로 병렬로 실행될 수 있음을 쉽게 알 수 있습니다.

이 분석은 단순 전송만 지원하는 블록체인에서 사실입니다. 그러나 사용자가 작성한 이체 계약에 어떤 작업이 있는지 정확히 알 수 없기 때문에 이러한 분석이 튜링 완전하고 스마트 계약을 실행하는 블록체인에 입력되면 충분히 정확하지 않습니다.

가능한 상황은 다음과 같습니다. A → B 트랜잭션은 C 및 D의 계정 상태와 관련이 없는 것으로 보이지만 사용자의 기본 구현에서 A는 특수 계정이며 A 계정을 통해 이체되는 모든 자금은 먼저 C에서 이체할 경우 일정 수수료가 계좌에서 차감됩니다. 이 시나리오에서는 세 개의 트랜잭션이 모두 관련되어 있으므로 병렬로 실행할 수 없습니다. 트랜잭션도 기존 종속성 분석 방식에 따라 구분하면 문제가 발생할 수밖에 없습니다.

그렇다면 사용자의 계약 내용을 기반으로 트랜잭션에 실제로 어떤 종속성이 존재하는지 자동으로 추론할 수 있습니까? 대답은 부정적입니다. 정적 분석에서 언급했듯이 계약 종속성 및 실행 프로세스를 분석하는 것은 어렵습니다.

FISCO BCOS는 계약 내용에 더 익숙한 개발자에게 트랜잭션 종속성을 지정하는 작업을 할당합니다. 특히 트랜잭션이 의존하는 상호 배타적인 리소스는 일련의 문자열로 나타낼 수 있습니다. FISCO BCOS는 인터페이스를 개발자에게 노출합니다.개발자는 트랜잭션이 의존하는 리소스를 문자열 형식으로 정의하고 체인의 실행자에게 알립니다.실행자는 자동으로 블록의 모든 트랜잭션을 트랜잭션 DAG로 정렬합니다. 개발자가 지정한 트랜잭션 종속성 . 예를 들어, 단순 이체 계약에서 개발자는 각 이체 트랜잭션의 종속성을 {송신자 주소 + 수신자 주소}로 지정하기만 하면 됩니다. 또한 개발자가 전송 논리에 다른 타사 주소를 도입하는 경우 종속성을 {발신자 주소 + 수신자 주소 + 타사 주소}로 정의해야 합니다.

이 방법은 보다 직관적이고 구현하기 간단하며 보다 일반적이며 모든 스마트 계약에 적용할 수 있지만 그에 따라 개발자의 어깨에 대한 책임도 증가합니다. 개발자는 트랜잭션 종속성을 지정할 때 매우 주의해야 합니다. 종속성이 올바르게 작성되지 않으면 결과를 예측할 수 없습니다.

병렬 프레임워크 계약FISCO BCOS는 개발자가 병렬 계약의 프레임워크를 사용할 수 있도록 몇 가지 계약 작성 사양을 설정했습니다. 세부 사항은 다음과 같습니다.병렬 뮤텍스두 트랜잭션이 병렬로 실행될 수 있는지 여부는 두 트랜잭션이 존재하는지 여부에 달려 있습니다.。

상호 배타적

• . 상호 배제는 두 거래가작업 계약 저장 변수 집합 간에 교차가 있습니다.예를 들어 전송 시나리오에서 트랜잭션은 사용자 간의 전송 작업입니다. transfer(X, Y)를 사용하여 사용자 X에서 사용자 Y로의 전송 인터페이스를 나타내면 상호 배제는 다음과 같습니다.상호 배타적인 매개변수

• :계약상호 작용

, 계약 저장 변수의 "읽기/쓰기" 작업과 관련된 매개변수입니다. 예를 들어 전송 인터페이스는 transfer(X, Y)이며 여기서 X와 Y는 상호 배타적인 매개변수입니다.

뮤텍스

: 트랜잭션에서 상호 배타적인 매개변수에 따라 추출된 특정 상호 배타적인 콘텐츠. 예를 들어 전송 인터페이스가 transfer(X, Y)이고 이 인터페이스를 호출하는 트랜잭션에서 특정 매개변수가 transfer(A, B)이면 이 작업의 상호 배타적 개체는 [A, B]입니다. 호출 매개변수는 transfer(A, C)이고 이 작업의 뮤텍스 개체는 [A, C]입니다.

두 트랜잭션이 동시에 병렬로 실행될 수 있는지 여부를 판단하는 것은 두 트랜잭션의 상호 배타적인 대상이 겹치는지 여부를 판단하는 것입니다. 서로 교차가 비어 있는 트랜잭션은 병렬로 실행될 수 있습니다.

FISCO-BCOS는 병렬 계약을 작성하는 두 가지 방법을 제공합니다. 하나는 견고성 계약이고 다른 하나는 미리 컴파일된 계약입니다. 여기서는 견고성 계약만 소개하고 사전 컴파일된 계약은 동일합니다.

견고성 계약 병렬 프레임워크

Parallel Solidity 컨트랙트를 작성할 때 기본적으로 ParallelContract.sol을 병렬이 필요한 컨트랙트의 기본 클래스로 사용하고 registerParallelFunction() 메서드를 호출하여 병렬 인터페이스를 등록하기만 하면 됩니다.

parallelContract 코드는 다음과 같습니다.

• 다음은 병렬 프레임워크 계약을 기반으로 작성된 이적 계약서입니다.

인터페이스가 병렬화 가능한지 확인

병렬 계약 인터페이스는 다음을 충족해야 합니다.

외부 계약에 대한 호출이 없습니다.

• 다른 기능을 호출하기 위한 인터페이스가 없습니다.

상호 배제 매개변수 결정

인터페이스를 작성하기 전에 인터페이스의 상호 배제 매개 변수를 결정해야 합니다. 인터페이스의 상호 배제는 전역 변수의 상호 배제입니다. 상호 배타적인 매개변수를 결정하는 규칙은 다음과 같습니다.

• 인터페이스는 전역 매핑에 액세스하고 매핑 키는 상호 배타적인 매개변수입니다."globalA",• 인터페이스는 전역 배열에 액세스하며 배열의 아래 첨자는 상호 배타적인 매개변수입니다.

• 인터페이스는 단순 유형의 전역 변수에 액세스하며 단순 유형의 모든 전역 변수는 뮤텍스 매개변수를 공유하고 서로 다른 변수 이름을 뮤텍스 객체로 사용합니다.예: 계약에는 여러 단순 유형의 전역 변수가 있으며 서로 다른 인터페이스가 서로 다른 전역 변수에 액세스합니다. 서로 다른 인터페이스를 병렬화해야 하는 경우 전역 변수를 수정한 인터페이스 매개 변수에 상호 배타적인 매개 변수를 정의하고 호출 시 사용할 전역 변수를 지정해야 합니다. 호출 시 해당 수정된 전역 변수의 "변수 이름"을 mutex 매개 변수에 능동적으로 전달하여 이 트랜잭션의 mutex 개체를 나타냅니다. 예를 들어 전역 매개변수 globalA가 setA(int x) 함수에서 수정된 경우 setA 함수는 set(string aflag, int x)로 정의되어야 하며 호출 시 setA(

10) 변수 이름 "globalA"를 사용하여 이 트랜잭션의 뮤텍스 개체가 globalA임을 나타냅니다.string、address、uint 256、int 256 상호 배타적인 매개변수를 결정한 후 규칙에 따라 매개변수 유형 및 순서를 결정합니다. 규칙은 다음과 같습니다.

매개변수 유형 및 순서 결정

- 인터페이스 매개변수는 다음으로 제한됩니다.

(향후 더 많은 유형이 지원될 예정입니다.)- 상호 배타적인 모든 매개변수는 인터페이스 매개변수의 상단에 배치됩니다.。

Khipu

알 수있는 바와 같이,

실제로 FISCO-BCOS 트랜잭션 병렬 처리는 주로 사용자가 작성한 계약 사양에 의존합니다. 사용자가 작성한 컨트랙트가 표준화되지 않은 상태에서 시스템이 성급하게 병렬 실행하면 원장 루트 불일치 문제가 발생할 수 있습니다.

첫 번째 레벨 제목

개요

FISCO-BCOS와 달리 오류 없이 계약을 작성할 때 정적 충돌이 발생할 주소 범위를 사용자가 식별하고 표시하는 것은 비현실적이라고 Khipu는 생각합니다.

경쟁이 발생할지 여부, 장소 및 조건은 결정론적 획득이 현재 상태와 관련될 때만 판단할 수 있습니다. 현재 계약 프로그래밍 언어로는 코드의 정적 분석을 통해 완벽하게 오류가 없고 누락되지 않은 결과를 얻는 것이 거의 불가능합니다.

키푸는 이와 관련하여 종합적인 시도를 하여 프로젝트 수행을 완료하였습니다.

프로그램 세부정보

Khipu의 구현에서 동일한 블록의 각 트랜잭션은 이전 블록의 세계 상태에서 시작한 다음 병렬로 실행되어 실행 중에 이상적인 경험 경로에서 만난 위의 세 가지 경주를 모두 기록합니다. 병렬 실행 단계가 끝나면 병합 단계로 이동합니다. 병합 단계에서는 병렬 세계 상태가 하나씩 병합되며, 트랜잭션 병합 시에는 이전에 병합된 경쟁 조건과 충돌이 있는지 기록된 정적 조건에서 먼저 판단합니다. 그렇지 않은 경우 직접 병합하십시오. 그렇다면 이전에 병합된 세계 상태에서 시작하여 이 트랜잭션을 다시 실행하십시오. 최종 병합된 세계 상태는 블록의 해시로 마무리됩니다. 이것이 최후의 방어선이며 검증이 잘못되면 이전의 병렬 방식을 포기하고 블록의 트랜잭션이 순차적으로 다시 실행됩니다.병렬성 지수：

Khipu는 여기에 병렬성 지수, 즉 재실행 없이 결과를 직접 병합할 수 있는 블록의 트랜잭션 비율을 도입했습니다. Khipu는 이더리움에서 제네시스 블록부터 최신 블록까지 며칠간의 재생 관찰을 통해 이 비율(병렬성)이 평균 80%에 달할 수 있음을 발견했습니다.

일반적으로 컴퓨팅 작업을 완전히 병렬화할 수 있다면 더 많은 CPU 코어가 항상 노드에 추가될 수 있기 때문에 단일 체인의 확장성은 무한합니다. 그렇지 않은 경우 최대 이론 속도는 다음과 같이 제한됩니다.

안달의 정리

시스템 속도를 높일 수 있는 한계는 병렬화할 수 없는 것과 반대입니다. 즉, 시간의 99%를 병렬화할 수 있다면 100배의 속도 향상을 달성할 수 있습니다. 그러나 95%의 병렬화만 달성할 수 있다면 20배의 속도 향상만 달성할 수 있습니다.

충돌 마커

이더리움의 모든 트랜잭션을 다시 재생해보면 트랜잭션의 약 80%가 병렬화가 가능하고 20%는 병렬화가 불가능하므로 이더리움 속도를 높이는 Khipu의 평균 효율성은 약 5배입니다.

evm 코드 명령어의 해석을 통해 일부 제한된 명령어가 저장을 위한 읽기 및 쓰기 프로세스를 생성하므로 이러한 읽기 및 쓰기 위치를 기록하여 읽기 및 쓰기 세트를 형성할 수 있다는 충돌이 있음을 알 수 있습니다. 정적 코드 분석만으로는 이러한 프로세스가 기록되는지 확인할 수 없으므로 각 블록에서 트랜잭션을 처리할 때 각 트랜잭션을 병렬로 미리 실행해야 합니다. 사전 실행 프로세스를 통해 이러한 트랜잭션이 동일한 계정 또는 저장소에 읽고 쓰는지 여부를 알 수 있으며 각 트랜잭션에 대한 readSet 및 writeSet을 생성할 수 있습니다. 즉, 사전 실행 프로세스는 먼저 모든 트랜잭션의 초기 상태로 world state의 여러 복사본을 만드는 것입니다. 블록체인에 100개의 트랜잭션이 있다고 가정하면 이 100개의 트랜잭션은 스레드 풀을 통해 병렬로 실행될 수 있습니다. 각 계약은 동일한 초기 세계 상태를 가지며 실행 중에 100개의 readSets 및 writeSets가 생성되고 각각 100개의 새 상태가 생성됩니다.

이더리움 메인넷의 트랜잭션 재생을 통해 충돌이 많은 곳에서 대부분 동일한 블록의 거래소에서 수행되는 상호 연관된 트랜잭션임을 알 수 있으며 이 프로세스와도 일치합니다.

Aptos

프로세스 흐름도

특정 병렬 실행 프로세스

첫 번째 레벨 제목

개요

Aptos는 Diem의 Move 언어와 MoveVM을 기반으로 처리량이 많은 체인을 만들어 병렬 실행을 가능하게 했습니다. Aptos의 접근 방식은 사용자/개발자에게 투명하면서 연관성을 감지하는 것입니다. 즉, 트랜잭션은 자신이 사용하는 상태(메모리 위치)의 어느 부분을 명시적으로 명시할 필요가 없습니다.

프로그램 세부정보

Aptos는 Block-STM이라는 수정된 버전의 소프트웨어 트랜잭션 메모리를 사용하여 Block-STM 논문을 기반으로 병렬 실행 엔진을 구현했습니다.

Block-STM은 MVCC(Multi-Version Concurrency Control)를 사용하여 쓰기-쓰기 충돌을 방지합니다. 동일한 위치에 대한 모든 쓰기는 tx-id와 쓰기 tx가 재실행된 횟수를 포함하는 버전으로 저장됩니다. 트랜잭션 tx는 특정 메모리 위치의 값을 읽을 때 MVCC에서 tx 이전에 나타난 위치에 쓰여진 값과 관련 버전을 가져와 읽기-쓰기 충돌이 있는지 확인합니다. Block-STM에서 트랜잭션은 블록 내에서 미리 정렬되고 실행 중에 프로세서 스레드 간에 분할되어 병렬로 실행됩니다. 병렬 실행에서 트랜잭션을 실행할 종속성이 없다고 가정하면 트랜잭션에 의해 수정된 메모리 위치가 기록됩니다. 실행 후 모든 트랜잭션 결과가 검증됩니다. 유효성 검사 중에 이전 트랜잭션에 의해 수정된 메모리 위치에 액세스하는 트랜잭션이 발견되면 트랜잭션이 무효화됩니다. 트랜잭션 결과를 새로 고치고 트랜잭션을 다시 실행하십시오. 이 프로세스는 블록의 모든 트랜잭션이 실행될 때까지 반복됩니다. Block-STM은 다중 프로세서 코어를 사용할 때 실행 속도를 높입니다. 가속은 트랜잭션 간의 상호 의존도에 따라 달라집니다.

Aptos가 채택한 방식은 위에서 언급한 Khipu와 대략적으로 유사하지만 구현 세부 사항은 약간 다릅니다. 주요 차이점은 다음과 같습니다.

• Khipu는 블록의 트랜잭션에 대해 병렬 실행 및 순차 검증을 사용하는 반면 Aptos는 블록의 트랜잭션에 대해 병렬 실행 및 병렬 검증을 사용합니다. 두 옵션 모두 장점과 단점이 있습니다. Khipu의 체계는 구현하기 쉽지만 약간 덜 효율적입니다. Aptos의 Block-STM 구현은 많은 스레드에서 동기화 및 신호 작업을 사용하므로 코드로 구현하기 어렵지만 더 효율적입니다.

• Move는 기본적으로 글로벌 리소스 주소 지정을 지원하므로 병렬 실행에 도움이 되는 경우 Aptos는 블록 간에도 트랜잭션을 재정렬합니다. 관계자들은 이 솔루션이 병렬 효율성을 향상시킬 뿐만 아니라 MEV 문제를 해결할 수 있다고 주장하지만 이것이 사용자 경험에 영향을 미칠지는 여전히 고려해야 합니다.

벤치마크

Block-STM을 통합한 후 Aptos는 해당 벤치마크를 만들고 순차 실행과 병렬 실행의 경우 10k 트랜잭션 블록의 성능을 비교했습니다.결과는 다음과 같습니다.

위의 그림에서 알 수 있듯이 Block STM은 32개의 쓰레드가 병렬로 실행될 때 쓰레드의 순차 실행보다 16배 빠른 속도를 달성하며, Block-STM은 높은 경쟁 조건에서 8배 이상의 빠른 속도를 달성합니다.

첫 번째 레벨 제목

요약하다

요약하면 일부 솔루션은 사용자가 계약을 작성할 때 설정된 규칙에 따라 스토리지를 작성하도록 요구하므로 정적 및 동적 분석을 통해 종속성을 찾을 수 있습니다. Solana와 Sui는 비슷한 접근 방식을 취하지만 사용자 인식은 다릅니다. 이러한 솔루션은 본질적으로 더 나은 분석 결과를 얻기 위해 스토리지 모델을 변경하는 것입니다.

Khipu와 Aptos의 솔루션은 사용자를 인식하지 못합니다. 즉, 사용자는 계약을 신중하게 작성할 필요가 없으며 가상 머신은 실행 전에 종속성을 동적으로 분석하므로 종속성의 병렬 실행이 없습니다. 이러한 유형의 계획은 구현하기 어렵고 병렬 처리의 정도는 트랜잭션의 계정 분할에 어느 정도 의존합니다. 트랜잭션 충돌이 많은 경우 지속적인 재실행은 심각한 성능 저하로 이어집니다. 백서에서 Aptos는 종속성을 더 잘 분석하고 더 빠른 실행 속도를 달성하기 위해 향후 사용자 작성 계약에 일부 최적화가 이루어질 수 있다고 언급했습니다.

엔지니어링 구현 및 효율성 문제를 고려할 때 OlaVM은 Khipu+ 맞춤형 스토리지 모델 솔루션을 채택할 가능성이 높습니다. 성능을 개선하는 동시에 Block-STM 도입으로 인한 복잡성을 피하고 이후 단계에서 더 나은 엔지니어링 최적화를 촉진합니다.

2.FISCO-BCOS Github, FISCO-BCOS

3.Khipu Github, GitHub - khipu-io/khipu: An enterprise blockchain platform based on Ethereum

4.Aptos Github, GitHub - aptos-labs/aptos-core: Aptos is a layer 1 blockchain built to support the widespread use of of blockchain through better technology and user experience.

인용하다:

1. Block-STM 논문: [ 2203.06871 ] Block-STM: Ordering Curse를 Performance Blessing으로 전환하여 블록체인 실행 확장(arxiv.org)

첫 번째 레벨 제목

회사 소개

Sin7y는 2021년에 설립되었으며 최고의 블록체인 개발자들로 구성되어 있습니다. 우리는 프로젝트 인큐베이터이자 블록체인 기술 연구 팀으로서 EVM, 레이어 2, 크로스체인, 프라이버시 컴퓨팅 및 자율 지불 솔루션과 같은 가장 중요하고 최첨단 기술을 탐구합니다. 팀은 2022년 7월에 OlaVM 백서를 시작하여 빠르고 확장 가능하며 EVM과 호환되는 최초의 ZKVM을 구축하는 것을 목표로 했습니다.

WeChat 공개 계정: Sin 7 y

공식 홈페이지: https://sin 7 y.org/

백서: https://olavm.org/

Github：Sin 7 y

커뮤니티: http://t.me/sin 7 y_labs