Solana에서 Sui로

Sui와 Solana 개발의 가장 큰 차이점은 프로그래밍 언어에 있다. Sui는 Move를 사용하는 반면 Solana는 일반적으로 앱 개발과 관리를 단순화하는 개발 프레임워크와 함께 사용하는 Rust에 의존한다. Anchor는 가장 인기 있는 Solana 프레임워크이다.

주제	Rust (Solana)	Move (Sui)
Model	모든 데이터가 account에 저장되는 account 기반 모델이다. Program은 읽기/쓰기 account를 미리 선언한다. 모든 것이 account이다(program, data, wallet).	객체 소유권은 Sui에 내재되어 있으며, 객체는 일급 시민이고 Sui에서 소유되는 모든 것을 포괄한다.
Data storage	데이터는 instruction을 담는 stateless account인 program에 저장된다.	데이터는 Move 객체에 저장된다.
Inheritance	상속이 없다. Rust는 상속보다 공유 동작과 구성을 위해 trait를 사용한다.	인터페이스와 다형성이 없다. 그러나 Move에는 Type<T>와 같은 제네릭이 있다.
Dynamic dispatch	trait object를 통해 허용되지만 성능 오버헤드 때문에 Solana program에서는 일반적으로 사용되지 않는다.	허용되지 않는다
Asset and token accessibility	토큰은 Program Derived Address(PDA)에 저장된다. 접근은 program logic과 signer verification으로 제어된다.	누구나 공유 객체에 접근할 수 있다. 소유 객체는 객체 소유자만 접근할 수 있다.
Access control	signer 기반 접근 제어이다. Program은 트랜잭션 signer와 account 소유권을 검증한다. PDA는 program이 제어하는 account를 가능하게 한다.	주로 소유 객체를 통한 capability based access control이다. Identity 및 role 기반 접근 제어도 가능하다.
Contract upgrades	Program은 배포 시 upgradeable 또는 immutable로 표시할 수 있다. Upgrade는 program 바이너리를 교체하지만 같은 program ID를 유지한다.	새 contract는 이전 contract와 layout-compatible해야 한다. 공유 객체의 버전 관리를 고려해야 한다.
Mutate contract state	instruction data를 포함한 트랜잭션을 전송한다. Program은 instruction을 처리하고 account 데이터를 수정한다. Type-safe 클라이언트 상호작용을 위해 Anchor의 IDL(Interface Definition Language)을 사용할 수 있다.	런타임 프로그래머블 트랜잭션 블록 (PTB) 구성으로 트랜잭션을 전송한다.
Type safety	Rust의 타입 시스템으로 컴파일 시 강한 타입을 제공한다. 메모리 안전성은 borrow checker가 강제한다.	리소스 지향이며 linear type을 사용한다. 자산은 명시적으로 허용되지 않는 한 복사되거나 삭제될 수 없다. Move Prover를 통한 형식 검증으로 강한 타입 안전성을 제공한다.

객체 모델

Move에서는 모든 것이 객체이다. 객체는 Move 패키지(스마트 계약), 주소, 코인, NFT와 다른 모든 온체인 데이터를 담는 Sui의 기본 데이터 저장 단위이다.

객체를 NFT처럼 고유한 소유권 속성을 가진 자산으로 생각할 수 있지만, 이 개념은 모든 블록체인 데이터 전반으로 일반화된다. 모든 객체에는 소유권이 있다.

소유권

객체 소유권에는 몇 가지 세부 차이가 있지만 핵심 유형은 다음과 같다:

• 주소 소유 객체: 이 객체는 하나의 주소가 소유한다. 스마트 계약과 상호작용하지 않고도 이 객체를 전송하거나 받을 수 있다. 예를 들어 통화, NFT, 특정 함수 접근을 제한하는 토큰이 있다.
• 공유 객체: 누구나 사용할 수 있는 공개 접근 객체이다. 이 객체에 저장된 데이터를 변경하려면 일반적으로 스마트 계약에서 규칙을 정의해야 한다.

Sui의 모든 소유권 유형은 객체 소유권 유형을 참조하라.

접근 제어

Identity 또는 role 기반 접근 제어는 Solidity의 OpenZeppelin Ownable 및 AccessControl contract를 통해 널리 사용된다.

객체 소유권은 Sui에 내재되어 있으므로 contract function에 대한 접근은 일반적으로 capability objects로 제한된다.

이 객체를 사용자에게 발급하면 특정 함수를 호출할 권한이 부여된다. 사용자가 함수가 기대하는 객체를 소유하지 않으면 함수 호출은 실패한다.

주소 기반 검사를 구현할 수도 있다. 그러나 더 나은 보안을 위해 가능한 한 capability object를 사용하는 것이 권장된다.

자세한 내용은 The Move Book을 참조한다.

이 예시에서는 함수 호출 시 AdminCap 객체를 제시해야만 새 사용자를 생성할 수 있다.

/// Grants the owner the right to create new users in the system.
public struct AdminCap {}

/// Creates a new user in the system. Requires the `AdminCap` capability to be
/// passed as the first argument.
public fun new(_: &AdminCap, ctx: &mut TxContext): User {
    User { id: object::new(ctx) }
}

객체 변경

Rust에서는 데이터 구조가 program이 읽고 쓰는 별도의 account structure에 저장된다. Program은 stateless이며 접근할 account를 미리 선언한다. 데이터를 변경하려면 적절한 account reference가 포함된 트랜잭션에 서명해야 하며 program은 명시적 검사로 signer permission을 검증한다.

Move에서는 데이터를 변경하는 로직이 contract에 정의되지만 데이터는 Move 객체에 저장된다.

데이터를 변경하려면 객체 소유자가 PTB를 사용해 contract function을 호출해야 한다. 프로토콜 수준에서 소유권을 검사하므로 서명자가 참조된 객체에 접근할 수 없으면 트랜잭션은 실패한다.

프로그래머블 트랜잭션 블록

Rust에서 여러 program 호출의 결과를 연결하려면 일반적으로 여러 개의 순차 트랜잭션을 만들거나 program 내부에서 Cross-Program Invocations(CPIs)를 사용해야 한다. CPI는 program이 단일 트랜잭션 안에서 다른 program을 원자적으로 호출할 수 있게 하지만 깊이가 4단계로 제한되며 account 관리를 신중히 해야 한다. 클라이언트 측 트랜잭션 체이닝은 각 트랜잭션이 완료된 뒤 다음 트랜잭션을 제출해야 하므로 원자성 보장이 없다.

Move에서는 PTB가 이 문제를 해결한다. PTB는 빌더가 런타임에 원자성 보장을 유지하면서 contract 호출을 연결할 수 있게 한다. Sui PTB에는 최대 1,024개의 서로 다른 contract 호출 또는 다른 액션을 포함할 수 있다. PTB는 사실상 간단하면서도 표현력이 높고 강력하며 안전한 제한된 스크립팅 언어를 제공한다.

Sui의 빌더는 PTB를 활용해 다른 방식으로는 다루기 어려운 경험을 제공한다. 좋은 예는 최적의 가격으로 여러 DeFi 프로토콜에 걸쳐 토큰 스왑을 라우팅하는 DeFi aggregator이다. Sui에서 aggregator는 표시된 가격으로 트랜잭션이 실행되거나 완전히 revert된다는 보장을 가진 단일 PTB를 사용한다. PTB는 가장 강력한 Sui 기능 중 하나이다. 경험상 Sui에서 가장 성공적인 빌더는 이 기능을 단순한 트랜잭션 배치 수단으로 취급하지 않고, 초기에 자주 활용하는 빌더이다.

PTB에 관한 자세한 내용은 프로그래머블 트랜잭션 블록 (PTB)를 참조한다.

추가 비교

주제	Solana	Sui
Digital signature algorithm	Ed25519	Ed25519, secp256k1, secp256r1
Consensus mechanism	Proof of History (PoH)를 포함한 Tower BFT(PoS 변형)	DPoS
VM and its languages	Solana VM, Rust, C, C++	MoveVM, Move Lang
Chain data structure	PoH 순서를 가진 블록	DAG
Common standards (coin, token, NFT, and so on)	SPL Token, MPL Core, Token22	코인 표준, Closed-Loop Token
Coin names, name of the smallest unit	SOL, Lamport	SUI, MIST
Available frameworks for development	Anchor framework, Solana CLI, native Rust tooling	Sui CLI
L1 and L2	신흥 단계이며 널리 퍼지지는 않았고 대부분 병렬 실행이 가능한 빠른 L1에 의존한다	L2가 없으며 수평 확장이 가능한 빠른 L1에 의존한다
Governance	SIMD(Solana Improvement Documents)를 통한 오프체인 거버넌스	온체인 거버넌스
Bridges	지원된다	지원된다
Network security (stake required for control)	전체 stake의 66%(BFT requirement)	전체 stake의 66%
Smart contract auditing	account model 복잡성, PDA pattern, CPI 취약성 때문에 포괄적인 감사를 요구한다	더 적은 감사가 필요하며 언어가 일부 역할을 수행한다(객체 모델)
Private transactions	설계상 공개이다	설계상 공개이다
TVL (as of late 2025)	~10 billion	~2.6 billion
Implementation languages for clients	Rust, TypeScript (web3.js, @solana/kit), Python, Go	Rust, TypeScript, Python
Eventing	program log로 인덱싱되며 custom parsing 또는 indexer가 필요하다	sender, 객체 ID, type, timestamp로 인덱싱된다
Indexing	상위 수준 트랜잭션 데이터이며 custom indexer(Helius, Triton, Shyft)가 필요하다	상위 수준 트랜잭션 데이터 + 객체, 코인, GraphQL RPC 지원
Oracles	서드파티	서드파티
Network upgrade strategy	validator가 투표한 feature gate가 초과 정족수에 도달하면 활성화된다	protocol flag와 framework upgrade를 validator가 투표한 뒤 활성화한다
IDE	VSCode (Rust Analyzer)	VSCode (Move extension)
Transaction lifecycle	트랜잭션이 RPC에 제출되고 leader에게 전파되며 block에 포함되고 Tower BFT를 사용해 validator가 투표한다.	transaction certificate(실행 보장)를 생성하기 위해 클라이언트에서 validator로 두 번 왕복하고 공유 객체의 순서를 보장하기 위해 한 번 더 왕복한다.
Parallel execution	Sealevel runtime은 트랜잭션의 account 접근이 겹치지 않을 때 병렬 실행을 가능하게 한다. Account는 스케줄링을 위해 미리 선언해야 한다.	병렬 실행할 수 있는 트랜잭션은 병렬로 실행된다.
Storage fees, storage rebates	rent-exempt account는 최소 잔액을 요구한다. 2021년 이후 rent collection이 없고 rebate도 없다.	낮은 storage fee를 선불로 지불하며 객체를 파기하면 정리를 장려하기 위한 rebate가 있다.
Contract immutability	Program은 배포 시 upgradeable 또는 immutable로 표시할 수 있다.	객체인 upgrade capability를 사용해 native mutable 및 immutable 지원을 제공한다.
Contract upgrading	native이며 upgradeable로 표시된 program은 upgrade authority가 업그레이드할 수 있다.	native이며 upgrade capability가 중개한다.
Composability	Cross-Program Invocation(CPI)은 program이 트랜잭션 안에서 다른 program을 호출할 수 있게 한다. 깊이는 4단계로 제한된다. 트랜잭션 경계 안에서는 원자적이다.	PTB를 사용해 하나의 트랜잭션 안에서 임의의 수의 함수를 호출한다. 한 호출의 출력을 받아 다른 호출의 입력으로 넘겨 조합한다. PTB당 최대 1,024개의 명령으로 원자적 실행을 보장한다.
Token royalties	직접적이지 않다. MPL Core 같은 프로토콜이나 Token22 같은 extension으로 강제된다.	Kiosk와 transfer policy로 체인에서 강제된다.
Block time and finality	~400ms 블록 시간이며 ~12-13초 후 경제적 확정성을 가진다(Alpenglow 업그레이드 이전).	독립 트랜잭션은 sub-second finality를 가지며 공유 객체는 Mysticeti로 ~390ms이다.