*Sui가 제공하는 Sui Docs + 백서 + 추가적인 자료를 기반으로 작성한 글 입니다.
최근(?) 가장 핫한 레이어1를 고르자면 Aptos와 Sui를 뽑을 수 있는데, 생각보다 Aptos에 대한 정보는 국문으로 많이 나오는 반면 Sui의 경우 정보가 적은편. 그래서 공부한김에 정리해보는 조금 과장해서 제목을 지은 All about Sui.
About Sui
Sui는 Mysten Labs가 만든 레이어1 블록체인으로 크리에이터들과 개발자들이 매스 어덥션을 위한 경험을 제공할 수 있는 창작물/앱들을 만들 수 있는 인프라를 제공하는 것을 목표로 한다.
“Build without Boundaries”는 Sui가 추구하는 비전을 가장 잘 나타내는 문구.
Mysten Labs
Mysten Labs는 과거 페이스북의 디엠 블록체인 프로젝들의 핵심 인력들이 창업한 회사이다. 5명의 공동 창업자들(4명이 페이스북 출신)로 구성되어 있고 멤버들 또한 디엠 시절 인력으로 구성되어 있는 편. 총 인력은 35명 내외로 알려져 있다.
페이스북 출신이라는 백그라운드 + Move기반의 블록체인이라는 사실 때문에 Aptos와 자주 언급되는 편 이지만 베이스만 같을 뿐 체인의 설계 자체는 다르게 되어 있다. 최근 Mysten Labs는 $300M의 규모의 시리즈B펀딩을 끝내었고 약 $2B의 가치 평가를 받는 중 이다.
*Aptos에 관한 글은 A41의 Aptos 시리즈를 보면 매우 잘 설명되어 있다.
특징 요약
Sui는 다른 블록체인들과 어떻게 다를까?
기존 블록체인들은 각 트랜젝션들을 블록이라는 형태로 묶고 이들 기존의 블록체인에 추가하여 공개 분산형 장부를 이루는 구조로 운영된다다. 이 장부의 상태 (State)와 순서에 대한 동의(컨센서스)를 각 프로토콜의 룰 아래 노드들이 합의하는 방식은 지난 14년동안 성공적인 블록체인 시대를 이끌어 왔고, 다양한 네트워크들은 Byzantine Fault Tolerant를 목적에 맞게 변형시키면서 발전해왔다.
*Byzantine Fault Tolerant 는 전체 참여자 중 일부가 악의적으로 행동하더라도 네트워크의 목적성에 도달할 수 있는 장치/설계.
참고: BFT에 대한 설명
다만 이러한 전통적인 블록체인의 구조에서 지적되어온 문제점은 직렬처리 방식으로 인한 거래 속도의 저하 였고 이를 해결하기에 위해 이더리움 킬러라고 하는 여러 레이어들이 등장했지만 대게 탈중앙성을 포기하고 속도를 택한 경우가 많았으며 이더리움이 가지고 있는 “탈중앙화된 네트워크” 네러티브를 뺐어오지는 못했다.
Sui 또한 기존 블록체인의 구조가 비효율적이라고 주장한다. Sui는 애초에 블록체인의 많은 거래들은 대게 서로 상호작용하지 않거나 의존하지 않는 단일 일방향 거래가 많고 소유 주체가 그 순서를 정할 수 있기에 이러한 거래들은 순서 자체는 중요하지 않다 라는 조금더 극단적인 스탠스를 취한다.
Sui 블록체인은 기본적으로 병렬 처리 구조를 가지며 블록 중심이 아닌 개별 거래 중심으로 검증을 진행하여 Tx들의 검증이 동시에 이루어질 수 있게 한다. 또한 Sui는 자체적으로 정의하는 기준에 따라 특정 Tx에서는 순서를 합의하는 컨센서스를 스킵하고 서로 의존성이 있는 거래들에 한해서만 컨센서스 과정을 거친다. 컨센서스를 스킵하는 형태를 casual ordering, 의존성 있는 거래의 컨센서스 과정을 total ordering라고 칭하고. 이는 Sui의 Object라는 개념을 통해 이루어진다.
Object
다른 블록체인과 Sui를 구별짓는 가장 큰 특징 중 하나는 object(객체) 시스템. 이는 기존 블록체인들은 account의 단위로 이루어져 있고 이 account들의 집합 상태를 관리하는 장부 시스템이었다면, Sui 네트워크의 기본 단위는 object이며 Sui블록체인은 이 각 objecte들을 관리하기 위한 장부 시스템이다.
Object를 쉽게 설명하면 스마트 컨트랙트에 의해 프로그래밍 가능한 객체들을 의미하며 이를 Move Object 라고 부른다. 스마트 컨트랙트 자체도 object이며 이를 Move Package라고 부른다
코인 밸런스, NFT, 스마트 컨트랙트들 모두 하나의 object이고, 이들은 거래가 처리될때 각 object 유형에 따라 그룹화 되어 처리되는 구조를 가지고 있다.
Sui Co-founder의 비유를 빌리자면, 기존 블록체인은 목적지가 다 다른 사람들이 한 줄에 순서에 맞게 서서 버스를 기다리고, 각 티켓이 맞는지에 대한 확인을 하고 탑승, 그리고 모두 같은 곳에서 내리는 형태 였다면, Sui의 경우 각 사람들의 목적지(Object)에 따라 나누고 줄을 선 후 개개인 별로 티켓을 확인하며 목적지에 맞는 운송수단에 의해 이동하는 것이다.
<Object Metadata>
모든 object는 다음과 같은 Metadata를 포함하고 있다.
Unique ID → Tx(트랜젝션)가 object를 생성하고 나면 부여되는 고유id
Integer Version - Object안에 포함된 총 tx수. 최초 생성된 object의 version은 고로 1
Transaction Digest - 해당 object를 output으로 포함한 마지막 tx 정보
Owner - 해당 object를 엑세스 할 수 있는 소유권에 대한 명시. (뒤에서 설명할 예정)
위의 메타데이터들을 통해 검증인 또는 누구나 object들의 casual order history에 대해 알 수 있다.
<Object Ownership>
Object에는 총 4가지의 소유 형태가 존재하는데 그 형태에 따라 거래 처리 방법이 결정된다.
Owned by address: 가장 흔한 케이스로 object 생성후 소유권을 특정 주소에게 부여. 특정 주소가 소유한 object는 그 주소의 승인으로만 사용가능. 예를 들면 특정 주소가 소유하고 있는 NFT에 Tx를 발생시키고 싶다면, 이건 그 NFT라는 object를 소유하고 있는 주소로만 가능. 이때 Owned Object에 대한 Tx는 소유자가 순서를 결정하는 것 이기에 컨센서스 과정이 필요하지 않다.
Owned by another object: 다른 object에 의해 소유될 수 있는 object. A라는 object가 소유한 child object로 존재하는 형태로 이는 고유의 object로 인식되며 똑같이 Sui 저장소에 보관되는 형태. 이는 object wrapping이라는 개념과는 다른데, wrapping의 경우 A object가 B object가 속한 항목을 같이 포함했을때를 칭하는 것. 이때 wrapped된 B object의 경우 고유의 ID가 부여되지 않고 고로 Sui에도 저장되지 않는다. 대신 A object안에 속해 있는 형태로 볼 수 있고 이는 저장소에는 없지만 A object 속에 존재하는 형태로 유지된다.
Immutable: 그 누구도 건들 수 없고 소유하지 않는 object. Move Package (Smart contract) 처럼 한번 실행 되면 바꿀수 없는 것들이 immutable object이며 다른 object 들도 freeze_object API를 통해 immutable object로 전환 가능하다
Shared: 직역하자면 공유상태의 object. 누구나 트리거할 수 있는 object를 뜻하며 이는 순서를 정하는 컨센서스 과정이 필수로 요구된다. Owned Object의 경우 Tx의 순서를 본인 스스로 정할 수 있지만, Shared Object 경우 특정 소유주가 없기에 순서를 정하는 컨센서스 과정이 요구되는 것이다. 예를 들면 특정 누구나 엑세스 가능한 Dex의 스마트 컨트랙에 Tx를 발생시키는 경우, 컨센서스 과정이 진행이 된다.
Sui의 개발자들은 위의 Ownership 특성들을 조합하여 높은 자유도를 가지고 원하는 프로토콜 및 제품을 디자인을 할 수 있다.
검증/컨센서스
위에서 간단히 언급했듯이 owned objcet는 컨센서스를 스킵, shared object에는 컨센서스가 요구되는데, 이렇게 어떤 소유형태를 띈 object에 tx를 발생시키냐에 따라 처리 방법이 달라진다.
Owned vs Shared Object에 발생된 Tx들의 처리 과정을 검증/컨센서스 구조를 통해 비교해보자면 다음과 같다.
이때 몇가지 미리 알고 있으면 좋은 것들이 있는데,
Sui 네트워크는 반복되는 특정 Epoch (기간)을 주기로 운영되면 이 Epoch가 시작될때 참여하는 검증인들이 고정되고 이 구성은 Epoch가 끝날때 까지 바뀌지 않는다.이 검증인들을 Committee라고 부르며 새로운 Epoch의 Committee는 전 Epoch의 Committee로 부터 2/3이상의 승인을 받아서 진행된다.
Sui 네트워크는 owned object에서 있어서는 컨센서스를 스킵하고 검증 절차만 거치고, shared object에 한에서는 검증 이후 추가적인 컨센서스 과정을 진행한다.
<Owned Object>
Owned Object들의 Tx의 경우 단순 토큰을 전송하는 P2P형식의 Tx, 블록체인 기반 앱에서 메세지 전송, 대량 민팅, 투표, 등 순서를 합의 할 필요 없는 일방향성 거래이기에 이 경우에는 컨센서스 과정을 스킵 한다. 물론 이것이 아무런 검증 절차를 거치지 않는다는 것을 뜻하지는 않는다.
대신 Byzantine Consistent Broadcast 알고리즘 기반의 Fast Pay 형식을 사용하여 컨센서스 과정을 생략하고 검증 단계만 지나면 TX를 종결하는 구조이다. 쉽게 풀어서 이야기 하자면 Byzantine Consistent Broadcast 는 모든 검증 노드들이 동일한 Tx Request를 받을 수 있게 하는 알고리즘이고 Fastpay는 이를 기반으로 한 피어 리뷰 시스템을 통해 20명 검증인 기준 이론상 80,000 tps ,100ms를 가능케 한다. + 여기에 Sui는 dPoS (Delegated Proof of System - 사용자들이 본인의 Sui를 검증인들에게 위임할 수 있는 형태)를 적용해 Tx들을 처리한다.
이 과정은 아래와 같이 이루어진다.
발송인이 TX를 모든 검증인들에게 보낸다.
dPoS에 기반해 모든 검증인들은 본인들이 스테이킹한 Sui + Delegated (위임) 받은 Sui 양 만큼 투표의 가중치를 부여받고, 전송받은 tx에 대한 투표를 실행한다.
발송인은 Byzantine Fault Tolerant에 충족하는 투표들을 certificate의 형태로 만들어 다시 검증인들에게 전송하고 tx를 종결한다.
이는 전송인 관점에서 추가적인 행위를 요구하지만 활용 방법에 따라 처리속도를 매우 큰폭으로 향상 시키는 방법이다.
<Shared Object>
Shared Object의 경우 단순 일방향적 Tx가 아닌 누구나 엑세스가 가능한 Smart Contract등의 같은 케이스이며, 이는 Narwhal, Bullshark, and Tusk 컨센서스 엔진을 사용해 처리된다.
우선 진행 과정을 먼저 이야기 해보자면 Owned Object의 검증 과정에서 추가적인 과정이 추가 되는데,
발송인이 TX를 모든 검증인들에게 보낸다.
dPoS에 기반해 모든 검증인들이 투표의 가중치를 부여받고, 전송받은 tx에 대한 투표를 실행한다.
발송인은 Byzantine Fault Tolerant에 충족하는 투표들을 certificate의 형태로 만들어 다시 검증인들에게 전송한다. 이때 certificate들은 Narwhal, Bullshark, and Tusk 컨센서스 엔진들을 통해 순서가 정해진다.
순서가 정해진 후, 발송인은 다시 한번 certificate을 검증인들에게 다시 전송하여 tx를 종결한다.
Narwhal, Bullshark, and Tusk 모두 DAG 시스템을 기반으로 하고 있는데, DAG는 쉽게 말해 블록을 검증하는 개념이 아닌 트랜잭션이 트랜잭션을 검증하는 구조라고 이해하면 쉽다. 예를 들어 새로운 트랜잭션을 추가할려면 이는 그 전 트랜잭션들을 참조하여 구성이 되어야 하며 + 특정 트랜젝션이 검증되기 위해서는 새로운 트랜젝션들에 의해 참조되어야 하는 형태이다. 이 방법은 트랜젝션들이 이전/새 트랜젝션들에 기반하여 검증되는 과정에서 형성된 그래프 (DAG)를 통한 거래 기록들의 역추적을 가능케 하고 기록 확인 및 이중지불 문제 방지를 가능케 한다.
<Narwhal>
Narwhal은 정확히는 Bullshark, and Tusk 컨센서스 알고리즘과 같이 쓰일 수 있는 Mempool 프로토콜이며이를 통해 데이터 수집과 컨센서스를 다른 레이어로 분리하는 것을 가능케 하여 블록체인의 성능을 향상 시키는 방식이다.
*Mempool은 전통적인 블록체인에서 Tx들이 처리되기 전에 저장되어 있는 공간을 뜻한다.
구체적인 설명을 하기 전에 Narwhal과 Bullsark/Tusk의 역할을 쉽게 정의 하자면
컨세선스 과정을 위한 데이터의 가동성을 보장 = Narwhal
Narwhal을 통해 나온 데이터에 대한 순서 합의 = Bullshark or Tusk
Narwhal는 라운드의 형태로 작동하는데 그 방식을 살펴 보면 다음과 같다.
r라운드에서 순서 정렬이 필요한 Tx들이 벨리데이터들을 통해 모여서 batch의 형태를 이루고 이를 “collection” 이라고 칭한다
*기존 Narwhal에서는 Block이라고 부르는데 이는 우리가 흔히 아는 블록체인의 Block과는 다른 것이 collection들이 유효하다고 판정 받기 위해서는 두가지 조건이 필요한데
r-1 라운드에서 발생한 유효한 collection 들의 정보를 포함하고 있어야 한다. 여기서 유효한 이란 2f +1이상의 벨리데이터에게 승인 받은 경우를 말한다.
벨리데이터들로부터 2f + 1 이상의 승인을 받아야 하고 이를 certificate of availability 라고 부른다.
*여기서 f는 발생할수 있는 악의적인 노드의 수를 뜻함. 즉 2/3 초과의 정직한 검증인들에게 승인 받아야 한다는 것.
그 후 r라운드에서 생성된 certificate of availability 를 r+1라운드로 공유한다.
<Bullshark>
이후 Narwhal에서 Certificate으로 검증된 data를 기반으로 Bullshark or Tusk 컨센서스 과정이 진행된다.
Bullshark에 대해서만 간단히 다루어 보자면, 위에서 언급했듯이 Narwhal에서 Certified된 data들의 순서를 합의하는 과정을 Bullshark가 담당한다.
*원리를 설명하기 전에 알고 가면 좋은 포인트는,
Bullshark 컨센서스 과정에서 검증인들 간의 어떤 커뮤니케이션도 없다 (이미 Narwhal을 통해 Tx에 대한 검증을 마친 상태).
퍼블릭 블록체인의 비동기적 특징 (모든 노드들이 같은 시간에 100% 같은 장부를 공유하지 못함. 이는 노드들간의 즉각적 통신이 보장되어 있지 않고 악의적 노드가 존재할 가능성이 존재) 때문에 컨센서스 과정에서 벨리데이터 마다 가지고 있는 DAG View(장부)가 다를 수 있음.
Bullshark 또한 라운드 형식으로 이루어져 있고 작동원리는 다음과 같다.
매 홀 수 라운드 마다 앵커 블록이라고 하는 리더 블록이 정해진다
이 앵커 블록에 대한 커밋(확정)을 매 짝 수 라운드에서 진행하게 되고 검증인들에게 f + 1 (잠재적 악의적 검증인들의 수보다 1 많은 양의 투표) 이상의 투표를 받으면 커밋되는 구조이다.
*위사진에서 4표 중 3표를 받은 A2앵커 블록은 커밋, 1표만을 받은 A1은 커밋되지 못하였다.
그렇다면 A1은 유효하지 않은 데이터인가? 그렇지는 않다. 이 현상은 위에서 언급한 비동기적 특성때문에 발생하는데, 각 검증인들이 같은 시점에 보고 있는 DAG 그래프의 상태가 다를 수 있기에 검증인2 은A1 앵커 블록의 커밋 조건 (f+1)에 맞는 상태를 보고 커밋한 반면, 검증인1 은 검증인4의 투표를 포함하지 않은 그래프의 상태를 보고 있기 때문에 커밋조건에 맞지 않다고 판단하여 A1을커밋하지 않았다.
이 경우 검증인 1은 추후에 커밋된 A2와 A1과의 경로를 찾는 과정을 거치고, 이때 경로를 찾게 된다면 A1또한 함께 커밋하여 A1 → A2의 순서를 확정짓는다. 이는 검증인1과 2처럼 다른 상태를 본 상황에서 발생하는 Order에 대한 괴리를 없애기 위한 장치이며 quorum intersection (한명의 검증자라도 앵커 A1을 규칙 아래 커밋했다면 검증인들이 다른 커밋된 블록들을 추적했을때 무조건 A1이 나오는 형태로 디자인) 이라는 개념으로 실현 가능하다.
예를 들어 앵커 i 라는 블록이 커밋되었을때 i -1과의 경로를 찾는 과정을 통해 설명하자면,
앵커 블록 i와 i-1과의 경로가 존재할 경우 앵커 i -1 → i의 순서를 확정
앵커 블록 i와 i-1과의 경로가 존재하지 않을 경우, i와 i-2의 경로를 검색
i와 i-2의 경로가 존재한다면 i-2 → i의 순서를 확정, 존재하지 않는다면 i-3의 경로를 검색
존재할떄까지 커밋된 i-n의 과정을 반복
*쉽게 정리하자면 위와 같은 과정을 거쳐 앵커블록들의 Casual Order 를 Total Order로 순서에 맞게 정렬/동의 하는 과정이 Bullshark 컨센서스이다.
위에서 언급했듯이 Narwhal은 데이터 수집과 컨센서스를 다른 레이어로 분리하는 것을 가능케 하여 블록체인의 성능을 향상 시킨다고 했는데, Narwal과 Bullshark의 원리를 보고 난 후 다음 그림을 보면 무슨 말인지 이해 될 것!
Owned 그리고 Shared Object의 Narwhal and Bullshark컨센서스 과정을 요약하자면 다음 그림과 같다.
보다시피 컨센서스가 필요없는 Owned Object의 경우 5개 단계를 거쳐 Finality에 도달하고, Shared Object의 경우 Certificate 생성과정에서 Narwhall and Bullshark를 통해 컨센서스 과정을 거쳐서 Finality에 도달한다.
Sui Tokenomics
Sui 네트워크의 네이티브 토큰은 SUI로 발행량이 100억개로 정해져 있다. Gas비용, 거번넌스 참여, PoS를 통한 벨리데이팅 등 여러 목적성을 가진는데 사실 이건 흔한 구조이기 때문에 스킵하자.
<Gas Pricing>
Sui의 가스 산정 방식은 좀 특이한데, Tx를 처리하는 비용과 그 해당 Tx가 요구하는 Data 저장량에 대한 비용을 같이 청구하는 방식이다.
저 수식을 간단히 뜯어보자면 Computation Units과 Storage Units은 Computation과 Storage의 처리량이고, Computation Price와 Storage Price는 Computation과 Storage를 처리 하기 위한 가격이다.
<Computation Price>
Computation Price는 다음과 같은 방식으로 계산된다.
수식에서 확인 할 수 있는 Reference Price는 유저들이 Tx처리를 위해 Gas비용을 낼때 참고할 수 있는 비용이고 이는 Epoch 기간 동안 고정되어 있다. Tip은 네트워크에 처리량이 몰릴때 유저들이 본인들의 Tx 우선 처리를 위해 추가로 낼 수 있는 비용이다 (이더리움의 tip시스템과 비슷).
Price Floor는 말그대로 Tx처리를 위해 내야하는 최소값으로, 이는 Tip이 이론상 음수 (-)가격으로 입력될수 있기에 적어도 사용자들이 Price Floor이상의 Gas 비용은 지불하게 하기 위한 장치이다. Comptutaion Price를 Price Floor보다는 높게 유지하기 위해 Price Floor는 주기적으로 업데이트 된다.
합리적인 Gas 비용을 유지하기 위해서는 Referecne Price를 신뢰할 수 있어야 하는데, 이를 위해 Sui는 총 세가지 방법을 사용한다.
Gas Price Survey - 각 Epoch가 시작할때 마다 검증인들에게 설문을 진행하여 그들이 Tx를 처리할 의향이 Gas가격대를 수집하고 이를 기준으로 Reference Price를 설정한다. 이 과정의 목적은 2/3이 이상의 검증인들이 동의하는 Tx를 처리하기 위한 최소 가격대를 정하는 것에 있다.
Tallying Rule - Epoch 기간 동안 검증인들은 다른 검증인들의 행동을 확인 할 수 있는 시그널을 받는다. 이를 통해 다른 검증인들의 행동에 대한 주관적 평가를 내리게 되는데, 이 평가 결과를 통해 네트워크에 이익에 맞게 행동하는 검증인들은 추가적인 보상을 받을 수 있는 Multiplier (승수) 를 부여받게 된다. 당연 그렇지 못한 검증인들은 적은 보상을 받는다. 여기서 말하는 이익에 맞는 행동이란 Survey에 제출한 최소 Gas 비용에 얼마나 근접하게 그리고 빠르게 Tx를 처리했냐를 말한다. 이를 통해 Survey에 실제로 검증인들이 처리할 의향이 있는 Gas 비용을 제출하게끔하고 실제로 처리도 그에 맞게 진행하게 하는 것이 Tallying Rule의 목적이다.
Incentivized Stake Reward Distribution Rule - 각 Epoch가 끝날때마다 검증인들은 Staking된 SUI에 대한 보상을 받는데, 이때 추가 보상 비율이 Survey와 Tallying Rule의해서 정해지게 된다. Tallying rule에서 나온 검증인 각 개인의 multiplier의 Median (중앙값)을 통해 Global Multiplier를 산정하고 아래 공식을 통해 Reward Share (각 검증인이 받는 보상)를 산출하여 Staking 보상을 지불한다.
GasSurveyBoost는 검증인들이 Reference Price보다 더 낮은 금액을 Survey때 제출하도록 유도하는 방식이다.
Reference Price보다 낮은 금액을 제출 → GasSurvey Boost > 0 → 추가 보상
Reference Price보다 높은 금액 제출 → GasSurvey Boost < 0 → 추가 보상 X
Computation Price 산출 메커니즘을 정리하자면
Survey 를 통해 검증인들이 동의하는 Reference Price를 설정하고
Tallying Rule를 통해 보상을 지불하여 검증인들이 실제로 Survey에 제출한 Gas비용 기준으로 Tx들을 처리할 수 있게 하며
Distribution Rule을 통해 낮은 비용을 Survey 제출하게 함으로써 합리적인 Gas비용을 공정한 경쟁을 통해 이루어낸다
Sui의 Gas 메커니즘은 각 Epoch에 제시된 Reference Price + Storage Price에 맞는 비용을 제출한 사용자들에게 매우 좋은 네트워크 경험을 제공하고, 이를 위해서는 신뢰 할 수 있는 Reference Price가 필수적이다. 그렇기에 네트워크는 검증인들이 합리적이고 신뢰할 수 있는 Reference Price를 산출하는데 기여하도록 인센티브를 제공하고 엔드 유저들 관점에서 Reference Price를 참고하여 Gas를 제출하게 되었을때 합리적으로 Tx가 처리될 수 있다는 컨센서스를 만들 수 있게 된다.
<Storage Price>
Storage Price는 유저들이 본인들의 Tx가 온체인에 저장되어야 할때 내는 비용이며, 이 수치는 고정되어 있다. Storage Price는 거버넌스 프로포절에 의해 정해지며 비주기적으로 업데이트될 예정. 지불된 Storage 비용은 Storage Fund라는 곳에 저장되는데, 이곳에 저장된 Storage비용은 미래의 검증인들에게 보상으로 돌아간다.
Sui Storage Fund는 이름 그대로 Storage 비용을 저장하는 Fund로써 검증인들이데이터를 저장하는데에 있어서 보상을 주기 위한 Fund이다. 이는 미래의 검증인들은 본인들이 처리하지 않은 데이터들 또한 저장해야 하는 추가적인 비용을 감수해야 하기에 미래의 사용자들이 이 비용을 떠넘겨 받지 않도록 Fund를 통해 미래의 검증인들에게 보상을 하기 위해 설계된 것이다.
공식을 간단히 설명하자면:
과거의 거래들로 Fund에 쌓인 Storage 비용 → 미래의 검증인들에 대한 보상
Sui PoS 메커니즘은 네트워크 전체에 스테이킹된 양을 Delegated Stake(위임된 Sui) + Storage Fund의 Sui의 합으로 각 Epoch마다 산정한다. 이 전체 스테이킹의 양의 보상을 1이라고 했을때 r 만큼이 검증인들에게 돌아가는 보상이고 1 - r 만큼의 남은 스테이킹 보상은 Storage Fund로 들어가게 된다. 그리고 이 Storage Fund로들어간 보상 (1-r)은 추후에 검증인들에게 돌아가는 Staking 보상에 Storage 인센티브로 포함되어 사용된다. 이로써 순수하게 Storage 비용으로 Fund에 쌓인 자본은 지출되지 않고 스테이킹 보상으로 Fund에 쌓인 Sui를 Storage 인센티브로 지출하기에 Storage Fund가 바닥나지 않는 구조를 만든다.
*물론 토크노믹스 백서를 읽어보면 Delegator들도 그들의 위임한 만큼 가져가는 보상 + 거기에서 검증인들이 때가는 수수료 + Delegator들의 보상은 전체 스테이킹 보상중 Storage Fund를 제외하고 산출 + 이자 구조 등의 세부 형태들이 존재하지만 그건 양이 방대하기에 Tokenomics 백서를 직접 참고하는게 더 좋을 듯 하다.
*아니면 따로 시리즈를 만들어서 이야기해보는게 좋을 수도
Move
*Move 언어와 솔리디티를 비교하면서 설명하고 싶지만 본인은 개발자가 아니라… Sui가 지적하는 현재 Smart Contract언어의 문제점과 Sui가 이를 Move를 통해 풀기 위해 공유한 문서 정도만 첨부해본다.
Sui가 지적하는 현재 Smart Contract언어의 문제점들은 다음과 같다. (사실 솔리디티 저격인거 같긴한지만)
Cross-Platform에 적합하지 않다. 현재 언어들은 블록체인의 트렌젝션 처리, 사인/해싱, 컨센서스 알고리즘에 너무 과하게 집중되어 있기에 이는 상호작용성을 매우 떨어트린다.
안전하지 않다. 개발자들은 본인들의 컨트랙트를 실행하기 전에 매우 많은 시간과 리소스를 보안/검사에 투자해야 하고, 코드 디자인의 실수는 수백만 달러의 피해를 낳는 경우가 빈번한다. (실제로 대부분의 해킹 사례가 스마트 컨트랙트에 대한 직접적인 공격으로 발생)
Smart Contract를 처리하는 레이어들이 매우 느리다. 애초에 레이어들이 Tx들을 순차적으로 처리하는 경우가 많기에, 언어 자체가 병렬 처리 또는 처리 속도 개선 가능성에 맞게 디자인 되지 않았다.
비성숙한 이코시스템. 기존의 언어 시장과 다르게 개발자들이 코드를 공유하고, 감사하고, 취약점에 대해 논의 하는 체재가 잡혀 있지 않기에, 누군가 만들어놓은 코드를 대량으로 여러명이 복사해서 사용하고 이는 온 체인 저장소에 대한 낭비를 야기한다.
안좋은 엔드 유저 사용자 경험. 레이어들과 언어의 디자인 자체가 엔드 유저에 맞추어져 있기 않기 때문에, 내가 소유한 자산들을 보는 과정 또한 제 3의 인프라/어플리케이션 의존해야 하는 경우가 많으며 이 과정은 매우 좋지 않은 사용자 경험을 불러오고 잠재적 피싱 위험에 노출되기도 한다.
그래서 Sui는 이런 문제점들은 Move라는 프로그래밍 언어와 Sui 블록체인을 통해 풀겠다는 것이다.
Move는 Rust를 기반으로 만들어졌으며 2018년 페이스북 (현 메타)에서 진행했던 Libra Project에서 시작되었고 Web3의 Java Script가 되는것을 목표로 했다.
Move언어 자체는 블록체인에 특화된 성질을 가지고 있지 않은 크로스 플랫폼 언어이기에 블록체인에서 필요한 account, tx, 암호학 같은 특성은 Move를 적용하는 각 블록체인들이 제공해야 한다. 이때 Move 언어를 포크 해야 되는 것이 아닌 동일한 Move Virtual Machine, Prover, Package Manager등을 사용하며 여기에 각 블록체인 레벨에서 원하는 기능을 추가 하는 형태이다.
페이스북에서 진행하던 Diem 프로젝트가 Move언어를 적용한 첫 블록체인 이었는데, 이때 Move와 Diem이 접목된 형태는 Smart Contract의 실 사용 케이스를 확장하기에 제약이 많았었다. 그렇기에 기존 Diem이 사용하던 Move언어를 그대로 Sui에 접목시킨 것이 아니라 Sui 블록체인에 적합한 Sui Move를 만들게 된 것 이다.
Diem이 사용하던 Move = 오리지널 Move
Sui가 사용하는 Move= Sui Move
오리지널 Move는 객체/자산 컨트롤을 중심으로 디자인되었고 Move Global Storage에 데이터를저장하는 반면, Sui Move는 객체(Obejct) 중심으로 Sui 저장소에 데이터를 따로 저장하는 형태를 가지고 있다.
더 자세한 정보는 아래 링크들에서 확인 가능하다.
https://medium.com/mysten-labs/why-we-created-sui-move-6a234656c36b
https://docs.sui.io/learn/sui-move-diffs https://medium.com/mysten-labs/why-we-created-sui-move-6a234656c36b
Sui의 생태계
그래서 Sui는 이더리움 및 다른 레이어1들의 생태계와 얼마나 다른 공간을 만들 수 있을까?
백서나 외부적으로는 본인들의 생태계가 얼마나 탈중앙화 되어 있고 빠르고 안전한지에 대해서 강력하게 주장하는 것이 당연하지만 이는 일단 메인넷이 나오고 실제로 어떤 생태계가 구성되는지를 가보아야 확인 가능한 부분인듯 하다.
개인적으로 레이어의 성능도 성능이지만 각 레이어가 생성해내는 네러티브가 레이어의 존속성에 큰 요소로 작동한다고 생각하는데, 그렇다면 Sui를 포함한 여러 레이어들은 본인들이 제공할 수 있는 기술적 한계/이점에 따라 생태계를 구성하고 이를 통해 각각의 네러티브를 생성하며 그에 맞는 생태계 확장을 이루어 나가지 않을까 넘겨짚어 본다. 그렇다면 레이어1들의 전쟁이 승자 독식으로 끝나는게 아니라 레이어 마다 특성/강점을 가지고 생태계를 확장 시키는 그림이 아닐까.
그런 관점에서 Sui는 어떤 생태계를 구성할 수 있을까?
일단 Sui의 Build without Boundaries에서 알 수 있듯이 블록체인의 매스 어덥션을 목표로 하는 체인이기에, 대중들에게 친숙한 경험을 제공함과 동시에 블록체인의 탈중앙화 네러티브를 접목시키는 방향이 가능하지 않을까 한다. 물론 단일 블록체인에서 빠른 속도와 탈중앙성 두 가지를 실제로 이루어 낸다는 전제하에 말이다.
NFT
지난 NFT Bull 마켓에서 보았던 단순 10K PFP NFT의 붐은 Sui 뿐만 아니라 다른 블록체인에서도 일어나지 않을 것이라 생각한다. PFP NFT = IP = 네러티브 라는 공식은 블루칩NFT 들의 성공을 관통하는 문법이라고 생각하는데, 이 공식에서 NFT가 어떤 레이어에서 발행되었나가 주는 네러티브 또한 상당하다고 느껴진다. 그렇다면 이더리움의 제공하는 네러티브 위에 지어진 흔히 블루칩이라고 불리는 IP들 말고 다른 레이어에서 이와 같은 규모의 NFT IP들이 나올 수 있을지에 대한 의문이 들며 Next 블루칩을 외치며 무수히 쏟아져 나왔던 지난 Bull마켓과 같은 모습은 나오지 않을 것 같다. *Doodles가 만약 솔라나 기반이었다면 지금과 같은 가치를 지닐 수 있었을까?
물론 벌써 이더리움에서 발행된 Sui Punk라는 NFT들이 나오는 것을 보면 분명 Sui의 메인넷 런칭 후 이런 Pump & Dump NFT프로젝트들이 쏟아져 나올 것은 기정사실인것 같다. 만약 Sui가 NFT 생태계의 확장을 도모한다면 그들이 주장하는 네트워크의 강점을 활용한 프로젝트들을 통해 이루어질듯 하다. 예를 들면 외부 조건에 따라 NFT의 메타 데이터를 업데이트하는 Dynamic NFT의 유즈 케이스들 그리고 NFT 프로젝트들이 활용 할 수 있는 편리한 Tool들을 도입으로 인한 확장을 통하지 않을까?
Game
체인이 출시되고 실제 게임들이 디자인되고 런칭되기 전까지 매우 오래 시간이 걸리겠지만, 벌써부터 Sui는 블록체인 게임들을 통한 매스 어덥션에 집중하는 모습이다. Sui나 Aptos의 메인넷 런칭이 기달려지는 이유는 블록체인 게임들의 지속 가능성을 논의할때 항상 이야기 해왔던 “게임 토크노믹스 모델의 지속가능하지 않은 형태” , “X2E의 네러티브 에서 벋어나지 못한 설계”, “온 체인 게임의 구현하기 위한 기술적 한계” 등 여러가지 이유들이 새로운 네러티브를 가진 레이어의 등장으로 조금더 명확해지지 않을까 싶기 때문이다.
다만 게임을 통한 매스 어덥션을 불러오기엔 실질적인 게임 생태계가 Sui 네트워크에 구성되는데까지는 매우 오랜시간이 걸릴 것이고, Sui가 게임 개발자들에게 제공할 수 있는 환경을 통해서 기존과 얼마나 다른 블록체인 게임들이 나올 수 있을지는 지켜봐야 한다. 애초에 과연 지금까지의 블록체인 게임들이 레이어의 성능때문에 지속가능성을 확보하지 못했을까? 오히려 네트워크를 구성하고 있는 사람들의 페르소나 문제 그리고 그 구성원을 베이스로 제품을 만들 수 밖에 없었던 시장의 구조적 문제였다고 생각한다. 게임 시장이 얼마나 치열한지 그리고 레퍼럴 중심의 커뮤니티인지를 생각해보면 좋은 제품/재미있는 게임이 나온다고 지속가능했을것인지 그리고 이를 통해 매스 어덥션을 이룰 수 있었을까에 대한 의문이 든다.
그렇다면 Sui확장성은 게임성이 좋은 게임을 온보딩 시켜 사람들을 끌어들이는 것이 아니라, 다른 경로를 통해 네트워크의 확장을 일으키고 그 확장성을 좋은 게임에 온보딩 시켜 부스팅하는 방식을 통할 수 있지 않을까. 물론 좋은 게임들이 폴리곤이나 Aptos가 아니라 Sui위에 만들어질 당위성은 무엇일지 고민해보아야 할듯.
Social Media
Aptos 그리고 Sui 둘다 Web3 Social Media를 강조하는 편인데, Sui가 특히 더 Owned Object라는 컨셉을 통해서 Web3 Social Media에 대한 레퍼런스를 많이 소개하는 느낌이다. 블록체인 기반의 Social Media들이 기존 Social Media들과 달리 가질 수 있는 특성/강점은 인격체의 사회적 지위에 대한 정량화라고 생각하는데 (한 사람의 온/오프라인 속 신분/컨텐츠가 얼마만큼의 가치를 가지는에 대한 수치화), 이 강점을 어필할려면 기본적으로 UX 측면에서 매끄러운 형태의 구동이 가능하다는 전제가 붙어야 한다 (그런 이유에서 Polygon에 Social Media들이 지어지고 있는 것 같다). Social Media에서 메세지를 보내거나 인터렉션하는 것들을 (정확한 유형에 따라 다르지만) Sui는 Owned Object로 구분지어 컨센서스를 스킵할 수 있다고 주장하기에 이를 활용한 실제로 어떤 어플리케이션 케이스가 나올 수 있을지 궁금하다.
DAO
DAO 관련한건 매우 주관적인 사견이지만, 레이어에서 거버넌스와 DAO들이 얼마나 활발히 운영되냐는 그 레이어가 얼마나 상대적으로 탈중앙화되어 있냐를 증빙한다고 생각한다. (이는 이더리움과 다른 레이어들의 거버넌스와 DAO의 활성도를 통해 확인 가능 - 추후에 데이터를 가지고 분석해본 글을 써볼 예정). 물론 이것이 이더리움의 탈중앙화 정도의 절대적 수치에 의한 증빙이 아니라 레이어가 가지는 “탈중앙화 네러티브”를 통한 추상적이고 주관적인 수치가 반영된 부분이 크다고도 생각한다.
그렇다면 Sui가 본인들의 네트워크를 확장시키며 그들만의 네러티브를 키워나갈때 NFT나 아트를 통한 IP 중심의 확장보단, Social Media, Gaming등을 통한 대중적 확장을 쫓음과 동시에 DAO와 거버넌스를 활성화 시킬 수 있는 조직/인프라/툴 들의 온보딩을 통해 탈중앙화 네러티브를 같이 접목 시키는 방향을 취해볼 수 도 있지 않을까.
*매스 어덥션에 취해 탈중앙화라는 코어 요소를 망각하는 접근 방식은 다른 레이어 + 중앙 DB기반 기술과 크게 다른 차별점을 생성해내지 못한다.
FYI: 위에서도 언급했지만 Sui에 관한 국문으로 된 정보가 많이 없기에 개인적으로 읽은 걸 좀 쉽게 정리하자는 취지로 쓴 글이기에 오류가 많을 가능성이 높기에, 지적 및 수정 요청 대환영입니다.