저자: 류홍린

블록체인 세계는 최근 몇 년 동안 눈부신 속도로 발전해 왔으며, 점점 더 눈부시게 발전하고 있습니다. 비트코인은 이론적 관점에서 "P2P 전자 화폐"라는 개념을 현실로 구현했고, 이더리움은 "스마트 계약"을 전면에 내세워 수많은 애플리케이션을 탄생시켰습니다. 그러나 그 이후 대부분의 새로운 퍼블릭 체인에 대한 이야기는 두 가지 범주로 나뉘었습니다. 하나는 이더리움과의 호환성을 주장하며 기존 생태계와 개발자를 "이전"하는 것이고, 다른 하나는 이더리움의 혼잡 문제를 해결하기 위해 성능 향상, 하드웨어 스태킹, 아키텍처 재설계에 집중하는 것입니다.

두 가지 경로 모두 성공을 거두었지만, 숨겨진 우려 사항도 남습니다. 이더리움은 호환성 덕분에 가장 번영하는 생태계를 이루었지만, 여전히 정체와 높은 수수료라는 오래된 문제에 시달리고 있습니다. 성능에 집중하는 일부 퍼블릭 체인은 인상적인 TPS를 달성하기 위해 고가의 하드웨어에 의존하지만, 이는 높은 운영 비용과 탈중앙화의 희생을 초래합니다. 다른 체인들은 복잡하고 계층화된 아키텍처를 가지고 있어 유지 관리가 어렵고 위험이 점점 더 뚜렷해집니다. 사용자 관점에서는 느리고, 비싸고, 비인간적이라는 인식이 종종 있습니다.

바로 이러한 배경에서 수이가 등장했습니다. "더 빠른 이더리움"이나 "더 저렴한 솔라나"를 요구하는 대신, 수이는 "기본 원칙에 기반한 재설계된 L1 퍼블릭 블록체인"이라고 자신 있게 선언했습니다.

처음에는 별로 신경 쓰지 않았습니다. 블록체인 세계는 항상 새로운 개념이 넘쳐나니까요. 하지만 점차 개발자로 일하는 친구들, 프로젝트를 살펴보는 투자자, 심지어 이전에는 퍼블릭 체인에 무관심했던 사람들까지 모두 수이에 대해 이야기하는 것을 알게 되었습니다. 그들은 수이가 이더리움이나 솔라나와는 정말 다르다고 말했습니다.

호기심에 홍린 변호사는 다음과 같은 질문을 던졌습니다. 이른바 "첫 번째 원칙"은 정확히 어디에 나타나는가? 이전 버전과 비교했을 때, 이 원칙의 강점은 무엇이며, 잠재적인 문제점은 무엇인가? 다음은 블록체인 애호가로서 제가 분석하고 생각한 내용입니다. 홍린 변호사는 기술적 배경 지식이 없으므로 제 진술 중 일부는 엄격하거나 정확하지 않을 수 있습니다. 부정확한 부분이 있더라도 양해 부탁드립니다.

자산이란 정확히 무엇인가요?

블록체인의 핵심은 본질적으로 자산을 기록하는 것입니다. 이는 자산을 온체인에서 어떻게 표현해야 하는지에 대한 의문을 제기합니다. 비트코인과 이더리움은 간단한 해답을 제시합니다. 바로 계좌와 잔액입니다. 누가 얼마를 가지고 있는지는 원장의 숫자 열로 표현됩니다. 이 접근 방식은 간단하지만 실제 자산과는 상당히 다릅니다. 콘서트 티켓은 개별적이며 한 번 구매하면 만료됩니다. 게임 내 장비는 레벨과 내구도를 가지고 있으며, 은행 담보 대출 계약은 특정 조건과 이자율을 갖습니다. 이 모든 것을 "계좌의 추가 잔액"과 같은 단일 문장으로 압축한다면, 이를 설명하기 위한 추가적인 논리가 필요할 것입니다. 따라서 이더리움은 잔액 모델의 단점을 해결하기 위한 패치로서 ERC-20, ERC-721, ERC-1155와 같은 표준을 지속적으로 도입해 왔습니다.

수이는 다른 접근 방식을 취했습니다. 이러한 논리를 고수하는 대신, 자산을 "객체"로 직접 모델링했습니다. 각 객체는 고유한 ID, 소유권, 속성을 가지며, 이러한 속성은 시간과 사용에 따라 변경될 수 있습니다. 티켓은 한 번 사용 후 자동으로 "사용됨"으로 표시되고, 검도 업그레이드되거나 손상될 수 있습니다. 다시 말해, 온체인 자산은 더 이상 단순한 숫자가 아니라 수명 주기를 가진 "살아있는 것"입니다. 이를 통해 복잡한 자산의 개발이 더욱 자연스러워지고 복잡한 논리적 설명이 필요 없게 됩니다.

물론 이러한 설계에는 대가가 따릅니다. Solidity에 익숙한 개발자는 객체의 수명 주기 관리에 다시 적응해야 합니다. 툴체인 또한 이에 발맞춰야 합니다. 그렇지 않으면 인덱서, 지갑, 거래소가 객체 모델에 맞춰져 있지 않을 경우, 개발자는 "균형 잡힌 사고방식"에 의존하게 될 수 있습니다. 더 현실적인 문제는 ERC 시리즈가 사실상의 글로벌 표준이 되었다는 것입니다. 이더리움이나 솔라나와 같은 생태계와 상호 운용될 때, Sui의 객체 로직은 추가적인 매핑 및 변환을 필요로 하며, 이는 번거로운 과정이 될 수 있습니다.

따라서 자산을 사물처럼 취급한다는 아이디어는 매력적이며, 실제로 실제 자산의 물리적 형태와 더욱 유사합니다. 그러나 이것이 진정으로 성공할 수 있을지는 포괄적인 생태계 구축, 표준화, 도구 지원, 그리고 크로스체인 상호운용성에 달려 있습니다. 그렇지 않으면 가장 우아한 개념조차도 이상과 호환성 사이에 갇힐 수 있습니다.

거래가 대기열에 있어야 하는 이유는 무엇입니까?

블록체인 세계의 고질적인 문제는 모든 거래가 하나씩 대기열에 쌓여야 한다는 것입니다. 이더리움은 각 블록 내에서 거래가 순차적으로 처리되도록 설계되었습니다. 이는 마치 도시에 계산원이 한 명뿐인 것과 같습니다. 커피를 사든 부동산 계약을 하든, 모두가 같은 줄을 서야 합니다. 누군가 시간을 허비하면, 그 뒤에 있는 사람들은 아무것도 하지 못하고 기다리게 됩니다. 이는 심각한 효율성 병목 현상을 야기합니다.

솔라나의 접근 방식은 이 요금소를 초고속 도로 요금소로 업그레이드하여 처리 속도를 높이고 고성능 하드웨어를 스태킹하여 단일 차선의 처리량을 극대화하는 것입니다. 결과적으로 이더리움보다 훨씬 빠르지만, 궁극적으로는 여전히 "단일 차선"이며, 단지 더 빠르게 실행됩니다. 하드웨어를 더 많이 스태킹할수록 비용이 증가하고 참여 노드에 대한 요구 사항이 더 엄격해지며 탈중앙화 수준은 낮아집니다.

수이는 다른 접근 방식을 취했습니다. 자산을 독립적인 객체로 모델링했는데, 서로 관련 없는 두 객체 간의 작업이 서로 기다려야 하는 이유는 무엇일까요? 그래서 실행 로직을 병렬화하도록 변경했습니다. 즉, 서로 다른 객체 간의 트랜잭션이 동시에 실행될 수 있고, 동일한 객체를 수정하는 작업만 대기열에 추가됩니다. 이는 단일 차선 고속도로를 다차선 고속도로로 변환하는 것과 같습니다. 대부분의 차량은 각자의 길로 가고, 같은 진입로를 두고 경쟁하는 차량만 대기열에 추가됩니다. 또한, 복잡한 다단계 작업을 단일 트랜잭션으로 묶어 한 번에 실행할 수 있도록 하는 프로그래밍 가능 트랜잭션 블록(PTB)을 설계하여 병목 현상이나 반복적인 확인 과정을 방지했습니다.

실용적인 비유를 하나 들어보겠습니다. 슈퍼마켓에서 계산을 한다고 상상해 보세요. 기존 이더리움 모델은 매장 전체에 계산대가 하나밖에 없습니다. 따라서 생수 한 병을 사든 트럭 한 대 분량의 식료품을 사든 같은 줄에서 기다려야 합니다. 솔라나의 방식은 이 계산대에 가장 빠른 바코드 스캐너와 가장 숙련된 계산원을 배치하지만, 줄은 여전히 하나입니다. 수이의 방식은 마치 열 개의 계산대를 두는 것과 같아서 대부분의 고객이 계산대를 분산시켜 효율성을 크게 향상시킬 수 있습니다.

이 설계는 잠재적 성능을 크게 향상시키고 "높은 동시성"을 가능하게 합니다. 하지만 공짜 점심은 아닙니다. 첫째, 시스템은 실행 전에 트랜잭션 간의 종속성을 파악해야 하는데, 이 자체에도 계산 오버헤드가 발생합니다. 마치 교통 경찰이 동시에 주행할 수 있는 차량과 충돌할 수 있는 차량을 먼저 파악한 후, 각 차량에게 주행을 지시하는 것과 같습니다. 트랜잭션이 너무 많으면 이러한 스케줄링만으로도 리소스가 소모됩니다. 둘째, 핫스팟 문제가 여전히 존재합니다. 인기 있는 오더북이나 NFT 계약과 같이 전체 네트워크가 경쟁하는 공유 객체가 나타나면 모든 관련 트랜잭션이 대기열에 들어가야 하며, 이러한 병목 현상은 사라지지 않습니다.

개발자에게 병렬 실행은 새로운 과제이기도 합니다. 순차 실행 환경에서는 로직이 비교적 간단하고 테스트 경로도 제어 가능합니다. 그러나 병렬 환경에서는 동시 읽기 및 쓰기, 상태 충돌 및 기타 문제를 고려해야 합니다. 제대로 설계되지 않으면 극단적인 경우 재현하기 어려운 버그가 발생할 수 있습니다. 이는 단일 스레드에서 다중 스레드 소프트웨어 개발로 전환하는 과정과 유사합니다. 성능은 향상될 수 있지만, 디버깅 및 검증의 복잡성은 기하급수적으로 증가하는 경우가 많습니다.

따라서 병렬 실행은 블록체인을 단일 스레드 실행의 한계에서 벗어나게 하는 새로운 길을 열어주었습니다. 그러나 대규모 애플리케이션을 구현하기까지는 스케줄링 오버헤드, 핫스팟 병목 현상, 개발자의 정신적 복잡성과 같은 실질적인 과제에 직면하게 됩니다.

안전을 위해 언어에 의존해야 할까, 아니면 습관에 의존해야 할까?

퍼블릭 체인의 보안 문제는 정교한 공격자보다는 언어 자체가 제공하는 과도한 자유에서 비롯되는 경우가 많습니다. 솔리디티가 대표적인 예입니다. 솔리디티의 유연성은 다양한 상상력을 자극하는 논리를 개발할 수 있도록 해주지만, 동시에 DAO 해킹, 재진입 공격, 정수 오버플로, 권한 관리 취약점 등 끔찍한 사건들이 끊임없이 발생하고 있습니다. 개발자의 부주의에서 비롯된 것이라고 주장할 수도 있지만, 다른 관점에서 생각해 볼 필요가 있습니다. 시스템의 보안이 인간의 끊임없는 경계에 의존한다면, 시스템의 규칙 자체는 본질적으로 취약할 수밖에 없습니다.

수이는 여기서 다른 접근 방식을 선택했습니다. 바로 Move 언어를 기반으로 스마트 계약을 구축하는 것입니다. Move는 페이스북의 Libra 프로젝트에서 시작되었으며, 핵심 개념은 "자원은 자원이다"입니다. 리소스는 언어 수준에서 일급 시민으로 취급됩니다. 기본적으로 리소스는 임의로 복사하거나 삭제할 수 없으며, 명확한 소유권 하에 전송되어야 합니다. 리소스를 전역 저장소에 저장하려면 특정 권한이 필요합니다. 이는 개발자가 "자발적으로 준수해야 하는" 관습이 아니라, 언어 규칙에 내장된 엄격한 제약 조건입니다. 다시 말해, 보안은 "습관"에 의존하는 것에서 "시스템"에 의존하는 것으로 전환되었습니다.

좀 더 현실적인 비유는 다음과 같습니다. 솔리드티는 가드레일이 없는 산길과 같습니다. 원하는 만큼 빨리 달릴 수 있지만, 미끄러지면 도랑에 빠집니다. 반면 무브는 가드레일, 제한 속도, 그리고 곳곳에 경사로가 있는 고속도로와 같습니다. 경험이 부족한 운전자라도 사고 가능성은 크게 줄어듭니다. 문제는 고속도로 건설 및 유지 관리 비용이 많이 들고, 고속도로 관련 규정이 지역별로 표준화되지 않으면 운전자들이 여러 지역을 횡단하는 데 어려움을 겪는다는 것입니다.

이러한 설계는 많은 일반적인 위험을 완화합니다. 이더리움 개발자는 종종 "이중 전송"이나 "무작위 토큰 생성"과 같은 오류를 신중하게 방지해야 합니다. Move에서는 이러한 취약점이 컴파일 시점에 방지됩니다. 이는 사용자 입장에서 계약 버그로 인해 자산이 사라지는 것을 훨씬 어렵게 만듭니다.

하지만 이러한 가드레일의 이면에는 진입 장벽이 존재합니다. Move의 프로그래밍 패러다임은 대부분의 엔지니어에게 익숙한 것과 근본적으로 다릅니다. Move를 처음 작성하는 Solidity 베테랑 개발자들은 제약을 느낍니다. 컴파일러가 값을 복사하는 것을 허용하지 않고, 객체를 삭제하려면 특정 조건이 필요합니다. 처음에는 프로세스가 눈에 띄게 느릴 수 있습니다. 더 복잡한 문제는 Move 생태계가 아직 미숙하다는 것입니다. Solidity는 수많은 라이브러리, 프레임워크, 감사 경험을 축적해 온 반면, Move의 툴체인, 감사 회사, 그리고 모범 사례는 아직 개발 중입니다.

흔히 간과되는 또 다른 현실은 Move가 Aptos와 Sui에서 완전히 구현되지 않았다는 것입니다. 즉, 개발자는 "한 번 배우고 어디에서나 사용할 수" 없습니다. 이러한 차이는 단기적으로 학습 비용을 증가시키고 Move 생태계를 쉽게 분열시켜 네트워크 효과를 약화시킵니다.

따라서 보안 관점에서 볼 때, 수이의 선택은 합리적입니다. 개발자의 신중함과 자기 관리에 의존하기보다는 언어 자체에 규칙을 직접 내장하는 것이 더 낫습니다. 그러나 생태계 관점에서 보면 이 길은 쉽지 않습니다. 개발자는 적응할 시간이 필요하고, 도구와 감사 시스템이 완성되어야 하며, 서로 다른 플랫폼 간의 파편화를 방지해야 합니다. 이러한 문제들이 제대로 해결되지 않으면, 아무리 좋은 보호 장치라도 "일부만을 위한 길"이 될 수 있습니다.

확장성은 무엇에 달려 있나요?

확장성은 거의 모든 퍼블릭 체인에서 피할 수 없는 문제입니다. 이더리움은 두 번째 계층을 구축하기로 했습니다. 메인 체인은 보안과 결제를 담당하고, 두 번째 계층은 대부분의 거래를 처리합니다. 이러한 접근 방식은 혼잡한 도시에 고가도로를 반복적으로 건설하는 것과 같습니다. 교통 흐름 분산에는 도움이 되지만, 상류와 하류 간 전환을 복잡하게 만들고, 크로스 체인 브리지는 사고 위험이 높은 영역이 됩니다. 솔라나는 정반대의 방식을 취하여 단일 머신의 성능을 한계까지 끌어올립니다. 마치 고속도로를 건설한 후 모든 차량이 그 위를 달리도록 강요하는 것과 같습니다. 결과적으로 속도는 빨라지지만, 비용이 많이 들고, 운전할 여유가 있는 사람이 줄어들어 탈중앙화가 저해됩니다.

수이는 세 번째 접근법을 제안했습니다. 온체인 자산을 독립적인 객체로 추상화하기 때문에, 이러한 객체는 여러 노드에서 독립적으로 분할 및 처리될 수 있습니다. 관련 없는 대부분의 객체는 병렬로 실행되며, 특히 인기 있는 공유 객체가 발생할 때만 중앙 집중식 조정이 필요합니다. 이는 마치 지하철 네트워크를 구축하는 것과 같습니다. 여러 노선이 서로 간섭하지 않고 동시에 운행되고, 몇몇 환승 허브에서만 혼잡이 발생합니다. 이론적으로 이 설계는 시스템이 수평적으로 확장될 수 있음을 의미합니다. 즉, 더 많은 사용자, 더 많은 노선, 그리고 더 큰 전체 용량을 확보할 수 있습니다.

하지만 종이 위의 청사진과 현실 사이에는 여전히 간극이 있습니다. 수이의 메인넷은 아직 수천만 명의 동시 사용자라는 극한의 테스트를 통과하지 못했습니다. 분산 시스템이 커질수록 스케줄링 및 일관성 문제는 더욱 복잡해지고, 지하철 노선이 많아질수록 배차 센터에 가해지는 압력은 기하급수적으로 증가합니다. 더욱이 노드의 경제 모델은 여전히 의문으로 남아 있습니다. 누가 노드를 안정적으로 장기적으로 운영할 의향이 있을까요? 보상이 너무 낮으면 유지 관리가 실패할 것입니다. 설계가 비논리적이라면 모두가 인기 있는 노드로 몰리고, 인기 없는 지역은 소외될 위험이 있습니다. 시간이 지남에 따라 이는 "악재가 양재를 몰아내는" 상황으로 이어질 수도 있습니다.

따라서 개념적 관점에서 볼 때, 수이의 확장성 솔루션은 "고가도로"나 "단일 차선 고속도로"보다 더 유연합니다. 그러나 연결성이 뛰어나고 안정적인 지하철 네트워크를 진정으로 구축하려면 기술 검증, 경제적 인센티브, 그리고 생태적 통합의 조율이 여전히 필요합니다.

생태계가 실제로 구현되었나요?

아무리 훌륭한 컨셉이라도 실제 적용이 없다면 허공에 떠 있는 성(城)에 불과합니다. 수이의 메인넷 출시는 금융에서 게임, 포털에서 전자상거래에 이르기까지 수많은 생태계 프로젝트를 육성하여 기초적인 생태계를 구축했습니다. 하지만 이 프로토타입이 성공적인 생태계로 성장하기까지는 아직 갈 길이 멉니다.

금융 분야에서 DeepBook은 인프라로 간주됩니다. DeepBook은 고성능 오더북 매칭 시스템을 온체인에서 운영하여 병렬 실행과 낮은 지연 시간을 활용하여 중앙 집중형 거래소처럼 매칭과 청산이 원활하고 원활하게 이루어지도록 보장합니다. 오더북은 금융 시장의 핵심이기 때문에 이러한 노력은 매우 중요합니다. 만약 제대로 작동한다면 고빈도 거래와 복잡한 전략을 지원할 수 있습니다. 그러나 오더북은 본질적으로 공유 객체이기 때문에 병렬 실행의 이점을 상쇄합니다. 핫스팟이 여전히 존재하며 성능에 병목 현상이 쉽게 발생할 수 있습니다. 더 현실적으로, 온체인 매칭이 시장 조성자와 기관 투자자를 진정으로 유치할 수 있을지는 재정적 검증과 심층적 검증이 모두 필요한 어려운 문제입니다.

Cetus는 탈중앙화 거래 및 유동성 프로토콜로 자리매김했습니다. 통합 라우팅을 제공하여 사용자가 여러 풀에서 최적의 가격을 협상할 수 있도록 지원합니다. 마치 "어디서나 승차 공유"를 의미하는 DeFi의 디디(Didi)와 비슷해 보입니다. 하지만 통합이 갑자기 깊이를 만들어내는 것은 아닙니다. 유동성은 여전히 투자자의 참여 여부에 달려 있습니다. 현재 Cetus의 거래량은 이더리움 기반 유니스왑의 일부에 불과하며, 생태계에 미치는 영향은 아직 미미합니다.

스캘럽 렌드(Scallop Lend)는 기관 수준의 품질과 결합성을 강조하는 대출 서비스를 제공하며, 더 많은 전문 참여자를 유치하고자 합니다. 대출은 디파이(DeFi)의 핵심이지만, 위험 관리는 여전히 외부 자금과 오라클에 의존하고 있습니다. 수이(Sui)의 고유한 아키텍처적 장점만으로는 이러한 "보이지 않는 손"을 대체할 수 없습니다.

사용자 진입 레벨에서 수이는 두 가지 흥미로운 도구, zkLogin과 스폰서드 트랜잭션을 제안했습니다. 전자는 사용자가 영지식 증명으로 보호되는 익숙한 계정으로 dApp에 로그인할 수 있도록 하여, 복잡한 온체인 개인 키 사용 경험을 사실상 숨깁니다. 후자는 신규 사용자가 토큰을 먼저 구매하지 않고도 직접 상호 작용할 수 있도록 합니다. 이러한 설계는 진입 장벽을 낮추지만, 동시에 새로운 질문을 제기합니다. 장기적으로 누가 스폰서드 트랜잭션 비용을 지불할 것인가? 건전한 비즈니스 모델이 없다면 이러한 경험은 지속 불가능할 수 있으며, 궁극적으로 사용자에게 먼저 토큰을 구매하도록 요구하는 기존 관행으로 회귀할 수 있습니다.

NFT 및 전자상거래 분야에서 수이(Sui)는 키오스크(Kiosk) 표준을 출시하여 상장, 보관, 결제, 이전 등 온체인 프로세스를 통합하고자 했습니다. 시장 간 마찰을 줄이고 자산 유동성을 개선한다는 이 개념은 타당합니다. 그러나 수이의 NFT 시장은 현재 전체 거래량이 제한적이며, 대부분의 상품에는 활발한 유통 시장이 부족합니다. 사용자와 자본 흐름이 없는 가장 정교한 표준조차도 여전히 고립되어 있습니다.

게임은 또 다른 핵심 분야입니다. Sui는 사무라이 쇼다운 R과 같은 유명 IP를 유치했고, 오리지널 블록체인 게임도 실험해 왔습니다. 객체 모델은 복잡한 게임 아이템을 표현하는 데 매우 적합합니다. 검을 업그레이드하고, 애완동물을 진화시킬 수 있는데, 이는 Sui 계약에서 자연스러운 "객체 상태 변경"입니다. 병렬 실행은 여러 사람이 동시에 상호작용할 때 발생하는 지연을 완화합니다. 하지만 게임의 지속성은 궁극적으로 플레이어의 참여 의지에 달려 있으며, 단순히 에어드랍을 활용하는 것뿐만 아니라 지속 가능성에도 달려 있습니다. 현재까지 Sui 기반 프로젝트 중 Axie Infinity만큼 세계적인 성공을 거둔 프로젝트는 없습니다.

이러한 노력 덕분에 수이는 허울 회사로 전락하는 것을 막을 수 있었지만, 여전히 해결해야 할 과제는 명확합니다. 사용자 규모와 거래량은 이더리움이나 솔라나에 비해 제한적입니다. 많은 프로젝트가 여전히 재단의 보조금에 의존하고 있으며 자립적인 비즈니스 모델이 부족합니다. 소위 "일상적인 애플리케이션"은 아직 등장하지 않았고, 일반 사용자가 체인을 사용할 수 있는 시나리오는 여전히 부족합니다. DeFi에서도 깊이와 위험 관리는 여전히 외부 자금에 의존하고 있으며, 체인 고유의 아키텍처적 이점은 시장의 콜드 스타트를 대체할 수 없습니다. 즉, 병렬 실행은 성능 문제를 해결할 수 있지만, 사용자와 자본을 자동으로 창출할 수는 없습니다.

수이의 생태계는 마치 새로운 쇼핑몰과 같습니다. 아름답게 장식되고 최첨단 디자인이 적용되었으며, 지하철 입구와 주차장까지 건설되었지만, 아직 사업체 수는 부족하고 고객 유입은 더욱 저조합니다. 재단이 일시적으로 임대료를 지원하고 몇몇 주요 브랜드를 유치할 수는 있지만, 쇼핑몰의 진정한 번영은 수익성 있는 사업과 탄탄한 고객층에 달려 있습니다. 이것이 앞으로 수이에게 진정한 시험대가 될 것입니다.

블록체인이 일반 사람들의 집에 어떻게 들어갈 수 있을까?

Web3를 처음 사용하는 대부분의 사람들은 초기 단계에서 어려움을 겪습니다. 지갑을 다운로드하고, 이해하기 어려운 니모닉 문구를 적어두고, 시작하기도 전에 네이티브 토큰을 구매하려고 하는 것입니다. 이러한 단계를 성공적으로 완료하더라도 높은 가스비, 실패한 거래, 긴 대기 시간 때문에 인내심을 잃는 경우가 많습니다. 오랫동안 Web3의 진입 지점은 비인간적인 장벽으로 가득 차 있었습니다.

수이의 디자인은 어느 정도 타깃형 솔루션입니다. 객체 모델은 온체인 자산을 현실 세계의 객체와 더욱 유사하게 만들어 이해하기 훨씬 쉽게 만듭니다. 예를 들어, 콘서트 티켓은 단순히 "계좌 잔액"이 아니라, 한 번 사용 후 자동으로 "사용됨"으로 표시되는 ID를 가진 티켓입니다. 게임 속 검은 더 이상 단순한 숫자가 아닙니다. 업그레이드, 손상, 심지어 재판매까지 가능한 객체입니다. 이를 통해 사용자는 온체인 자산을 처음 접할 때 "원장의 숫자"가 아닌 "객체"로 경험할 수 있습니다.

병렬 실행은 운영 속도를 높입니다. 기존 퍼블릭 체인에서는 자금 이체와 계약 배포가 같은 대기열에 대기합니다. 마치 커피를 사서 부동산 소유권을 같은 창에서 이전하는 것과 같습니다. Sui의 병렬 로직은 현실에 더 가깝습니다. 대부분의 경우 서로 다른 객체 간의 거래는 서로 간섭하지 않으며, 사용자는 클릭 즉시 피드백을 받습니다. 즉시 결제에 익숙한 일반 사용자에게 이러한 "지연 없는" 경험은 매우 중요합니다.

PTB(Programmable Transaction Block)와 결합하면 복잡한 여러 단계의 작업을 한 번에 완료할 수 있어 중간 단계 실패와 반복적인 확인으로 인한 불편함을 줄일 수 있습니다. 신규 사용자는 종종 오랜 시간 클릭하는 데 어려움을 겪다가 오류 메시지만 뜨고 어디가 잘못되었는지 알 수 없는 경우가 많습니다. PTB는 이러한 복잡성을 백엔드에 숨겨 사용자 경험을 "원클릭 완료"처럼 만들어 줍니다.

수이는 콜드 스타트 문제에 대한 해결책도 모색했습니다. zkLogin을 사용하면 사용자는 Google이나 Apple 계정으로 직접 로그인할 수 있어 공개 키, 개인 키, 니모닉과 같은 익숙하지 않은 시스템을 이해할 필요가 없습니다. 스폰서드 트랜잭션을 통해 신규 사용자는 토큰을 먼저 구매하지 않고도 첫 번째 블록체인 온체인 트랜잭션을 성공적으로 완료할 수 있습니다. 이는 진입 장벽을 크게 낮추며, 적어도 사용자가 지루한 첫 단계로 인해 어려움을 겪는 것을 방지합니다.

하지만 단순히 경험을 "그다지 나쁘지 않게" 만드는 것만으로는 충분하지 않습니다. 사람들을 블록체인으로 진정으로 이전하려면 Web2가 제공할 수 없는 애플리케이션 시나리오가 등장해야 합니다. 알리페이와 위챗은 이미 거의 마찰 없는 결제 경험을 완성했습니다. 이러한 경쟁사들과 경쟁하기 위해 수이는 이를 사용해야 하는 설득력 있는 이유를 제시해야 합니다. 예를 들어, 사용자가 진정으로 소유하고 임의로 동결할 수 없는 자산, 여러 애플리케이션에서 자유롭게 결합할 수 있는 경험(공식 채널을 통해서뿐만 아니라 2차 시장에서도 거래할 수 있으며, 컬렉션으로 패키징하여 게임에서 가상 아이템과 함께 전시할 수도 있음), 게임 소품은 더 이상 단일 업체의 서버에 고정되지 않고 여러 게임 간에 전송할 수 있음 등이 있습니다. 이러한 경험은 Web2가 달성할 수 없는 것이며, 수이가 활용해야 할 핵심 활용 사례입니다.

더 넓은 관점에서 볼 때, 수이의 접근 방식은 이전 세대와는 다릅니다. 자산을 잔액에서 객체로 변환하고, 병렬 거래를 활성화하고, 언어 규칙에 보안을 내장하고, 하드웨어를 분산 확장성으로 대체합니다. 생태계 전체에서 수이는 DeepBook, Cetus, Scallop과 같은 DeFi 프로젝트, zkLogin 및 스폰서드 거래 포털 설계, 키오스크 표준화 시도, 그리고 블록체인 게임 탐구를 통해 이 개념을 구현하고자 합니다.

그러나 직면한 과제들을 간과할 수는 없습니다. 객체 모델은 ERC 환경과 단절되어 상호 운용성을 위해 추가 비용이 발생합니다. 병렬 실행은 여전히 핫 객체(hot object)로 인해 병목 현상을 겪습니다. Move의 학습 곡선과 생태계 규모는 개발자 마이그레이션 속도를 제한합니다. 분산 확장성은 대규모 시나리오에서 아직 검증되지 않았습니다. 애플리케이션 생태계는 여전히 보조금에 의존하고 있으며, 실제 사용 사례는 아직 나타나지 않았습니다.

따라서 수이가 "첫 번째 원칙"에 기반한 탐구를 나타낸다면, 그 가장 큰 가치는 다른 길을 제시하는 데 있습니다. 이더리움 프레임워크를 수정하는 대신, 근본적인 질문을 다시 던지고 새로운 답을 제시하려는 시도입니다. 이러한 답이 얼마나 실현될지는 시간, 생태계, 정책, 그리고 시장의 종합적인 검증이 필요할 것입니다.

公链项目Sui推出开发者门户“Sui Developer Portal”

인기 기사