Aptos
-
한 때 Meta( 구 페이스북)의 블록체인 사업인 Diem (전 Libra) 프로젝트로부터 파생된 신생 Layer1(L1) 프로젝트 이다.
-
L1 레이어에서 확장성 문제를 해결하려는 초고속 블록체인이며, 자유로운 개발 환경을 갖춘 객체(Object) 중심의 블록체인으로 셀프 브랜딩을 하고 있다.
-
Aptos가 정석L1에 가깝고 Sui는 자유로운 개발 환경을 갖춘 객체(object)중심의 블록체인이다.
-
최근 옵티미즘과 스타크넷 토큰 출시 발표 및 폴리곤의 zkEVM 발표 등의 영향으로 모듈러 블록체인이 대세로 부상하고 있다. L1 vs L2 담론이 다시 한 번 대두되고 있음.
Aptos (The Safest and most Scalable Layer 1 blockchain)
가장 안전하고 확장성이 뛰어난 L1 블록체인
- 블록체인의 대중화를 위해선, L1의 보안(Security), 확장성(scalability)이 개선되어야 한다는 문제 의식에서 출범 하였다.
- 개방성(openness)을 통해 credible neutrality (신뢰할 수 있는 중립)를 확보하고자 한다.
확장성 및 퍼포먼스
-
Aptos는 160,000 TPS의 처리속도를 자랑한다. (이더리움, 아비트럼, VISA 각각 15, 500, 65,000) 다소 비현실적으로 느껴지긴하지만 비결은 BlockSTM 기술에 있다.
-
BlockSTM(Software Transactional Memory)
ACID 속성을 만족하는 데이터베이스 트랜젝션의 속성을 병렬프로그래밍에 적용한 기법 -
BlockSTM을 활용한 스마트컨트랙트 병렬 처리 엔진(Smart Contract parallel execution engine)이 있다 이 기술은 블록순서에 따라 트랜잭션을 순차적으로 처리하는 전통적인 블록체인 방식과 다르다
BlockSTM
-
독립적인 트랜젝션에 대해서는 여러쓰레드(thread)에 나눠 동시에 병렬적으로 실행(executuion) #참고: 솔라나도 sealevel으로 병렬 처리 가능.
-
트랜잭션 순서를 미리 결정 (Pre-defined order)
-
트랜젝션을 우선 실행한 뒤 검증(Validation) 및 합의 과정은 나중에 거침으로써 블록체인의 bottleneck를 해소하고 속도를 대폭 향상
-
다만, 실제로 트랜잭션의 검증 과정에서 충돌(conflict)이 생겨 롤백을 해야하거나 어떠한 이유로 커밋 작업이 중단되는 경우 TPS는 이보다 현저히 낮아질 수 있다.
BlockSTM 핵심 기술
낙관적 동시성 제어 (Optimistic Concurrency Control)
-
사용자들이 같은 데이터를 동시에 수정하지 않을 것이라고 가정하고 멀티 쓰레드를 사용하는 방식
-
트랜젝션을 우선 병렬로 처리하고 검증과정에서 충돌(Conflict)이 생겨 트랜젝션이 커밋되지 않으면, 롤백(rollback)하고 다시 실행 한다 .
-
모든 트랜잭션이 이상없다고 가정하고 우선 실행하는 Optimistic RollUp과 유사한 작동방식이다
-
대부분의 트랜젝션은 문제없이 처리 될 가능성이 높기에 해당방식을 사용 할 경우 속도가 비약적 상승함.
Dynamic dependency estimation (동적 의존성 추정)
-
검증에 실패하는 트랜젝션을 최대한 빨리 포착함으로써 비효율성을 줄이기 위한 장치이자, Commit 규칙을 정하는 방식이다.
-
검증자가 어떠한 트랜젝션 검증에 실패하는 경우 ESTIMATION이라고 태그해 논다.
-
다른 검증자가 해당 트랜젝션을 성공적으로 검증할 때까지 해당 트랜젝션과 의존성(dependency)이 존재하는 모든 트랜젝션들을 실행 및 검증하지 않고 우선 다음 트랜젝션으로 건너 뛰는 방식
-
만약 트랜젝션 검증에 실패하는데도 불구하고해당 트랜젝션과 의존성이 존재하는 트랜젝션들을 실행해 버리게 되면, 모든 작업을 RollBack 해야 하는 리스크가 존재하기에 해당 장치를 마련
Collaborative scheduler
-
트랜젝션의 검증과 실행 작업을 쓰레드에 할당해주는 기술로, 트랜젝션의 순서를 미리(pre-defined order) 정해줄 수 있도록 해준다.
-
트랜젝션 순서는 low transaction 위주로 먼저 처리하는데, 그 이유는 트랜젝션 실행과 검증 작업이 분리된 BlockSTM 구조 상 트랜젝션이 성공적으로 실행되었다고 해서 해당트랜젝션이 완전히 Commit 되는 것이 아니기 때문
-
트랜젝션 검증 과정 중 합의를 이루지 못하면 해당 트랜젝션 뿐 아니라, 그 이후에 발생한 트랜젝션까지 모두 롤백 해야 하기에, 최대한 시간 낭비 없이 효율적으로 블록체인을 운영하고자 high transaction을 먼저 실행하는 일은 피하도록 설계 됨.
Aptos 합의 알고리즘
Aptos - DiemBFT V4
-
Aptos는 HotStuff BFT 기반의 DiemBFT v4를 합의 알고리즘으로 채택.
-
DiemBFT는 가존의 PBFT(Practical Byzantine Fault Tolerance)를 개선한 알고리즘으로, PBFT대비 네트워크 부하가 적고 합의속도가 빠르다.
동기네트워크에서만 가능했던 BFT의 문제를 개선하여 비동기 네트워크에서도 합의를 이룰 수 있게 해줌.
-
PBFT의 골자는 비잔틴 노드(즉,배신자 노드)의 최대 개수가 f개라는 전제 하에, 전체 네트워크 노드 수가 3f+1개 이상이면 네트워크 내에서 이루어지는 합의를 신뢰 할 수 있다는 것.
(Cosmos, Eos, Ripple 등 대부분의 블록체인에서 PBFT를 조금씩 변형해서 사용)
DiemBFT 특징 3가지
-
linear communication과 chaining 기법을 통해 Finality, 지연시간 및 네트워크 효율 성 개선
-
pacemaker를 도입하여 효율적인 timeout 사용을 통해 검증자간 빠른 동기화 가능
-
평판시스템(reputation system)을 통해 온체인 현황을 분석하여 리더 노드를 선별하며, 문제가 있는 검증자들을 빠르게 필터링 함 .
기존 PBFT 검증 과정
PBFT
리더가 블록 생성 제안을 각 노드들에게 전파하면 , 노드들이 서로 교차 검증하는 방식
DiemBFT V1 검증 과정 (Linear Communication 및 chaining 방식)
DiemBFT
PBFT의 검증 과정을 간소화 하고 일방향으로 통일함으로써 노드간 커뮤니케이션 방식 개선.
DiemBFTV4 에서는 네트워크의 부담을 덜기 위해 검증자들이 현재 라운드가 아닌 다음 라운드의 리더에게 투표데이터를 전달한다.
진행과정
1. 리더가 블록 생성제안을 검증자들에게 각각 전파함.
2. 검증자들은 검증 결과에 대한 투표를 다음 라운드의 리더에게 전달
3. 2/3 이상이 검증자들이 투표를 성공적으로 전달한 경우 리더는 QC(Quorum Certificate)을 발행 한다.
