비교
이 페이지는 Sui가 다른 블록체인과 어떻게 비교되는지 요약하며, Sui의 잠재적 도입자가 자신의 사용 사례에 적합한지 판단할 수 있도록 하기 위한 것이다.
Sui 아키텍처에 대한 소개는 How Sui Works를 참고한다.
여기에는 Sui의 핵심 기능이 있다:
- Causal order vs. total order는 대규모 병렬 실행을 가능하게 한다
- Sui의 Move 변형과 object 중심 데이터 모델은 composable objects/NFTs를 가능하게 한다
- 블록체인 지향 Move programming language는 개발자 경험을 더 쉽게 만든다
Traditional blockchains
전통적인 블록체인 validator는 함께 공유 accumulator를 구축한다: 이는 블록체인의 상태를 암호학적으로 구속력 있게 표현한 것이며, 시간이 지남에 따라 block이라 불리는 증가분을 추가하는 체인이다.
결정적 확정성을 제공하는 블록체인에서는 validator가 블록체인에 증가분을 추가하려고 할 때마다, 즉 block proposal을 만들 때마다, 그 proposal을 시퀀싱한다.
이 프로토콜은 현재 체인 상태, 제안된 증가분의 유효성, 그리고 새로운 추가 이후 체인 상태가 어떠할지에 대해 합의를 형성할 수 있게 한다.
시간에 따라 공통 상태를 유지하는 이 방법은 비잔틴 장애 허용 분산 시스템 분야에서 지난 50년 동안의 풍부한 이론을 활용하며, 지난 약 14년 동안 실질적인 성공을 거두었다는 점이 알려져 있다.
하지만 이는 본질적으로 순차적이다: 체인에 대한 증가분은 진주를 실에 꿰듯 한 번에 하나씩 추가된다.
실제로 이 접근 방식은 현재 block을 검토하는 동안 transaction 유입을 멈추게 하며, 이러한 transaction은 종종 mempool에 저장된다.
Sui's approach to validating new transactions
많은 transaction은 상태의 서로 분리된 부분에서 작동하므로 서로 복잡한 상호 의존성이 없다.
금융 사용자는 흔히 자산을 수신자에게 보내기만 원하며, 이 단순한 transaction이 허용 가능한지 판단하는 데 필요한 유일한 데이터는 송신자 address의 최신 상태이다.
따라서 Sui는 전체 체인이 아니라 관련 데이터 조각에만 lock을 거는 접근 방식을 취하며, 이 경우에는 한 번에 하나의 transaction만 보낼 수 있는 송신자의 address이다.
Sui는 sender의 통 제 아래 있는 여러 요소에 명시적으로 의존할 수 있는 더 복잡한 transaction에도 이 접근을 확장하며, object 모델을 사용하고 Move의 강한 ownership 모델을 활용한다.
의존성이 명시적이어야 한다고 요구함으로써, Sui는 transaction 검증에 multi-lane 접근 방식을 적용하여 그러한 독립적인 transaction 흐름이 서로의 방해 없이 진행되도록 보장한다.
그렇다고 해서 플랫폼으로서의 Sui가 transaction 간 순서를 전혀 정하지 않거나, 소유자가 자신이 소유한 object의 작은 세계에만 영향을 미칠 수 있게 한다는 뜻은 아니다.
Sui는 일부 shared state에 영향을 미치는 transaction도 엄격하게 합의 순서에 따라 처리한다.
합의 엔진에 대한 자세한 내용은 State-of-the-art consensus 섹션을 참고한다.
A collaborative approach to transaction submission
Sui는 전통적인 block에 transaction을 일괄 처리하지 않고 개별적으로 검증한다.
이 접근 방식의 핵심 장점은 낮은 지연 시간이다; 성공한 각 transaction은 transaction이 Sui 네트워크에 자신의 effects를 지속적으로 남길 것임을 누구에게나 증명하는 finality certificate를 빠르게 획득한다.
하지만 transaction 제출 과정은 조금 더 복잡하다.
그 조금 더 많은 작업은 네트워크에서 발생한다.
(대역폭 비용이 더 저렴해지고 있으므로, 이는 덜 우려되는 사항이다.)
일반적인 블록체인은 동일한 작성자에게서 오는 여러 transaction을 fire-and-forget 방식으로 수락할 수 있지만, Sui transaction 제출은 다음 단계를 따른다:
- Sender가 transaction을 모든 Sui validator에게 브로드캐스트한다.
- Sui validator는 이 transaction에 대한 개별 vote를 sender에게 보낸다.
- 각 vote는 Proof of Stake 규칙에 따라 각 validator가 weight를 가지므로 일정한 weight를 가진다.
- Sender는 이 vote들을 비잔틴 저항 다수결 _certificate_로 모아 모든 Sui validator에게 브로드캐스트한다.
- Validator는 transaction을 실행하고 결과에 서명한다.
- Client가 결과의 비잔틴 저항 다수결을 받으면 _finality_에 도달하며, 즉 transaction이 폐기되지 않을 것이라는 보장이 생긴다.
- 선택적으로 sender는 vote를 조합하여 transaction의 effects를 자세히 설명하는 certificate를 만든다.
이 단계들은 sender에게 더 많은 것을 요구하지만, 이를 효율적으로 수행하면 여전히 최소 지연 시간으로 finality의 암호학적 증명을 얻을 수 있다.
원래 transaction 자체를 작성하는 일을 제외하면, transaction의 session 관리는 어떤 개인 키에도 접근할 필요가 없으며 제3자에게 위임할 수 있다.
A different approach to state
Sui는 단일한 state 집합이 아니라 특정 object를 관리하는 데 집중하기 때문에, 이를 보고하는 방식도 고유하다:
- Sui의 모든 object는 고유한 version 번호를 가진다
- 모든 새 version은 그 자체도 version이 있는 object들인 여러 dependency를 포함할 수 있는 transaction으로부터 생성된다
그 결과 Sui Validator는 object의 인과적 이력을 보여줄 수 있으며, 제네시스 이후의 이력을 나타낼 수 있다.
Sui는 많은 경우 한 object의 인과적 이력과 다른 object의 인과적 이력 간 순서가 중요하지 않다고 명시적으로 가정하며, 이 정보가 중요한 소수의 경우에는 이 관계를 데이터에서 명시적으로 드러낸다.
Causal order vs. total order
기존의 대부분의 블록체인 시스템과 달리, 그리고 독자가 위의 쓰기 요청 설명에서 짐작했을 수도 있듯이, Sui는 shared object인 경우를 제외하고 client가 제출한 transaction에 항상 total order를 부과하지는 않는다.
대신 많은 transaction은 causally ordered된다--transaction T1이 transaction T2에서 입력 object로 사용되는 출력 object O1을 생성하면, validator는 T2를 실행하기 전에 T1을 실행해야 한다.
인과 관계가 존재하려면 T2가 이 object를 직접 사용할 필요는 없다는 점에 유의한다--예를 들어 T1은 이후 T3가 사용하는 출력 object를 생성할 수 있고, T2는 T3의 출력 object를 사용할 수 있다.
하지만 인과 관계가 없는 transaction은 Sui validator 가 어떤 순서로든 처리할 수 있다.
State-of-the-art consensus
Mysticeti는 다중 proposer, 고처리량 합의 알고리즘에 대한 수십 년의 연구가 만든 최신 변형을 나타내며, 상용 암호화와 영구 저장소를 갖춘 WAN 환경에서 초당 400,000건이 넘는 transaction 처리량에 도달한다.
Where Sui excels
이 섹션은 전통적인 블록체인에 비해 Sui의 주요 장점을 요약한다.
High performance
Sui의 주요 selling point는 전례 없는 성능이다.
다음 bullet point는 전통적인 블록체인에 비해 Sui가 가지는 주요 성능상의 이점을 요약한다:
- Sui는 많은 transaction에 대해 합의를 생략하는 반면 다른 블록체인은 항상 total order를 부과한다
- Transaction을 인과 순서로 정하면 Sui는 많은 transaction의 실행을 대규모로 병렬화할 수 있고, 이는 지연 시간을 줄이며 validator가 모든 CPU 코어를 활용할 수 있게 한다
- Sui는 복잡성을 가장자리로 밀어낸다: client가 여 러 프로토콜 단계에 관여한다
- 이는 validator 간 상호작용을 최소화하고 validator 코드를 더 단순하고 효율적으로 유지한다
- Sui는 더 나은 사용자 경험을 위해 client 작업의 대부분을 Sui Gateway 서비스에 오프로드할 가능성을 항상 제공한다
- 반대로 전통적인 블록체인은 fire-and-forget 모델을 따르며 client는 자신의 transaction 제출 성공 여부를 판단하기 위해 블록체인 상태를 모니터링한다
- Sui는 프로토콜 단계 사이에서 시스템 timeout을 기다리지 않고 네트워크 속도로 작동한다
- 이는 네트워크 상태가 좋고 공격받지 않을 때 지연 시간을 크게 줄인다
- 반대로 여러 전통적인 블록체인의 보안은 transaction을 커밋하기 전에 미리 정의된 timeout을 기다려야 한다
- Sui는 validator당 더 많은 머신을 활용해 성능을 높일 수 있다
- 전통적인 블록체인은 흔히 validator당 단일 머신 또는 심지어 단일 CPU에서 실행되도록 설계된다
Performance under faults
Sui는 단순 transaction, 즉 owned object만 포함하는 transaction을 처리하기 위해 leaderless 프로토콜을 실행한다.
그 결과 결함이 있는 validator는 성능에 의미 있는 영향을 주지 않는다.
Shared object가 포함된 transaction의 경우, Sui는 view-change sub-protocol이 필요 없는 최첨단 합의 프로토콜을 사용하므로 성능 저하를 약간만 겪는다.
반대로 leader 기반 블록체인의 대부분은 validator 하나만 충돌해도 처리량이 감소하고 지연 시간이 증가하며, 이는 종종 한 자릿수 배수가 아니라 그보다 큰 폭이다.
Security assumptions
많은 전통적인 블록체인과 달리, Sui는 네트워크에 대해 강한 synchrony 가정을 두지 않는다.
이는 매우 나쁜 상황을 포함한 불리한 네트워크 조건, network split/partition, 또는 validator를 겨냥한 강력한 DoS 공격 하에서도 Sui가 보안 특성을 유지한다는 뜻이다.
동기식 블록체인, 즉 대부분의 작업 증명 기반 블록체인에 대한 지속적인 네트워크 공격은 자원의 이중 지출과 deadlock으로 이어질 수 있다.
Efficient local read operations
Sui의 읽기 프로세스는 다른 블록체인과 매우 다르다.
소수의 object와 그 이력에만 관심이 있는 사용자는 낮은 세분성과 낮은 지연 시간으로 인증된 읽기를 수행한다.
Sui는 제네시스부터 시작하는 좁은 object family tree를 생성하므로 transaction sender와 연결된 object만 읽을 수 있다.
시스템의 전역 뷰가 필요한 사용자, 예를 들어 시스템을 감사하려는 사용자는 성능 향 상을 위해 checkpoint를 활용할 수 있다.
전통적인 블록체인에서는 transaction에 total order를 부과하기 위해 family가 서로에 대해 순서화된다.
그러면 필요한 정확한 정보를 얻기 위해 거대한 blob을 질의해야 한다.
디스크 I/O가 성능 병목이 될 수 있다.
Easier developer experience
Sui는 개발자에게 다음 이점을 제공한다:
- Move와 object 중심 데이터 모델은 composable objects/NFTs를 가능하게 한다
- 자산 중심 프로그래밍 모델
- 더 쉬운 개발자 경험
Engineering trade-offs
이 섹션은 전통적인 블록체인에 비해 Sui의 주요 단점을 제시한다.
Design complexity
전통적인 블록체인은 하나의 합의 프로토콜만 구현하면 되지만, Sui는 두 개의 프로토콜이 필요하다: (i) 단순 transaction을 처리하기 위한 Byzantine Consistent Broadcast 기반 프로토콜과 (ii) shared object가 있는 transaction을 처리하기 위한 합의 프로토콜이다.
이는 Sui 팀이 훨씬 더 큰 코드베이스를 유지해야 함을 의미한다.
Shared object가 포함된 transaction은 합의 프로토콜에 제출되기 전에 약간의 오버헤드, 즉 두 번의 추가 round trip을 필요로하며, 잘 연결된 client가 Sui Gateway 서비스를 사용할 때는 200ms이다.
이 오버헤드는 위에서 설명한 두 프로토콜을 안전하게 조합하는 데 필요하다.
다른 블록체인은 대신 transaction을 합의 프로토콜에 직접 제출할 수 있다.
이 오버헤드가 있어도 shared object transaction의 finality는 여전히 2~3초 범위라는 점에 유의한다.
효율적인 synchronizer를 구축하는 일은 전통적인 블록체인보다 Sui에서 더 어렵다.
Synchronizer sub-protocol은 validator가 데이터를 공유하여 서로를 업데이트할 수 있게 하고, 느린 validator가 따라잡을 수 있게 한다.
전통적인 블록체인에 효율적인 synchronizer를 구축하는 일도 쉽지는 않지만, 여전히 Sui보다 단순하다.
Sequential writes in the simple case
전통적인 블록체인은 모든 client transaction을 서로에 대해 totally ordered한다.
이 설계는 validator 전반에서 합의에 도달해야 하므로 효과적이지만 느리다.
앞선 섹션에서 언급했듯이, Sui는 많은 transaction의 지연 시간을 줄이기 위해 դրանց에 대한 합의를 생략한다.
이 방식으로 Sui는 multi-lane 처리를 가능하게 하고 head-of-line blocking을 제거한다.
다른 모든 transaction은 더 이상 단일 lane에서 첫 번째 transaction의 증가분이 완료되기를 기다릴 필요가 없다.
Sui는 각 transaction에 적절한 폭의 lane을 제공한다.
단순 transaction은 sender address만 보면 되므로 시스템 용량이 크게 향상된다.
이러한 단순 transaction에서 sender에 대한 head-of-line blocking을 허용하는 단점은 sender가 한 번에 하나의 transaction만 보낼 수 있다는 점이다.
그 결과 transaction이 빠르게 finality에 도달하는 것이 필수적이다.
Complex total queries
Sui는 transaction에 항상 total order를 부과하지 않으므로 전통적인 블록체인보다 total query를 더 어렵게 만들 수 있다.
Total query는 local read에 비해 꽤 드물지만 특정 시나리오에서는 유용하다.
예를 들어 새 validator가 네트워크에 참여하여 전체 state를 디스크에 다운로드해야 하거나, 감사자가 전체 블록체인을 감사하려 할 수 있다.
Sui는 checkpoint로 이를 완화한다.
Checkpoint는 인증된 transaction에서 비롯된 블록체인에 증가분이 추가될 때마다 수립된다.
Checkpoint는 프로그램이 완전히 실행되기 전의 state를 저장하는 write ahead log와 매우 유사하게 작동한다.
그 프로그램의 호출은 블록체인의 스마트 계약을 나타낸다.
Checkpoint는 transaction뿐 아니라 transaction 전후 블록체인 상태에 대한 commitment도 포함한다.
Sui는 epoch 변경 시 도착하는 state commitment를 사용한다.
Sui는 여러 validator로부터 하나의 응답만 요구하며, 블록체인 상태를 나타내는 hash를 도 출하기 위해 보조 프로토콜을 활용한다.
이 프로토콜은 적은 대역폭을 소비하며 transaction 수집을 방해하지 않는다.
Validator는 epoch이 바뀔 때마다 checkpoint를 생성한다.
Sui는 validator가 이보다 더 자주 checkpoint를 생성하도록 요구하기도 한다.
따라서 사용자는 어느 정도의 노력으로 이러한 checkpoint를 사용해 블록체인을 감사할 수 있다.
Conclusion
요약하면, Sui는 성능과 사용성에서 상당한 향상을 제공한다.
이는 단순 send transaction을 위한 혁신적인 fastpath consensus를 도입하고, 낮은 지연 시간과 높은 처리량으로 업계를 선도하는 최첨단 합의 프로토콜을 활용한다.