Solana에서 Sui로
Sui와 Solana 개발 의 가장 큰 차이점은 프로그래밍 언어에 있다. Sui는 Move를 사용하는 반면 Solana는 일반적으로 앱 개발과 관리를 단순화하는 개발 프레임워크와 함께 사용하는 Rust에 의존한다. Anchor는 가장 인기 있는 Solana 프레임워크이다.
| Topic | Rust (Solana) | Move (Sui) |
|---|---|---|
| Model | 모든 데이터가 accounts에 저장되는 account 기반 모델이다. Programs는 읽기/쓰기 accounts를 미리 선언한다. 모든 것이 account이다(programs, data, wallets). | 소유권은 Sui에 내재되어 있으며 objects는 일급 시민이고 Sui에서 owned 되는 모든 것을 포괄한다. |
| Data storage | 데이터는 instructions를 담고 있는 stateless accounts인 programs에 저장된다. | 데이터는 Move objects에 저장된다. |
| Inheritance | 상속이 없다. Rust는 공유 동작과 상속보다 구성을 위해 traits를 사용한다. | interfaces와 polymorphism이 없다. 그러나 Move에는 Type<T>와 같은 generics가 있다. |
| Dynamic dispatch | trait objects를 통해 허용되지만 성능 오버헤드 때문에 Solana programs에서는 일반적으로 사용되지 않는다. | 허용되지 않는다 |
| Asset and token accessibility | 토큰은 Program Derived Addresses(PDAs)에 저장된다. 접근은 program logic과 signer verification으로 제어된다. | 누구나 shared objects에 접근할 수 있다. Owned objects는 object owner만 접근할 수 있다. |
| Access control | Signer 기반 access control이다. Programs는 transaction signers와 account ownership을 검증한다. PDAs는 program이 제어하는 accounts를 가능하게 한다. | 주로 owned objects를 통한 capability based access control이다. Identity 및 role 기반 access control도 가능하다. |
| Contract upgrades | Programs는 배포 시 upgradeable 또는 immutable로 표시할 수 있다. Upgrades는 program binary를 교체하지만 동일한 program ID를 유지한다. | 새 contracts는 이전 것과 layout-compatible해야 한다. Shared objects의 버전 관리를 고려해야 한다. |
| Mutate contract state | instruction data를 포함한 transactions를 전송한다. Programs는 instructions를 처리하고 account 데이터를 수정한다. Type-safe 클라이언트 상호작용을 위해 Anchor의 IDL(Interface Definition Language)을 사용할 수 있다. | 런타임 프로그래머블 트랜잭션 블록 (PTB) 구성을 통해 transaction을 전송한다. |
| Type safety | Rust의 타입 시스템으로 컴파일 시 강한 타입을 제공한다. 메모리 안전성은 borrow checker가 강제한다. | 리소스 지향이며 linear types를 사용한다. Assets는 명시적으로 허용되지 않는 한 복사되거나 삭제될 수 없다. Move Prover를 통한 형식 검증으로 강한 타입 안전성을 제공한다. |
Object model
Move에서는 모든 것이 object이다. Objects는 Move packages( 스마트 계약), addresses, coins, NFTs, 그리고 다른 모든 온체인 데이터를 담는 Sui의 기본 데이터 저장 단위 역할을 한다.
Objects를 NFTs와 같이 고유한 ownership 속성을 가진 assets로 생각할 수 있지만 이는 모든 blockchain 데이터 전반으로 일반화된다. 모든 object는 ownership을 가진다.
Ownership
Object ownership에는 몇 가지 뉘앙스가 있지만 핵심 유형은 다음을 포함한다:
- Address-owned objects: 이 objects는 하나의 address가 소유한다. 스마트 계약과 상호작용하지 않고도 이 objects를 전송하거나 받을 수 있다. 예를 들면 currency, NFTs, 또는 특정 functions 접근을 제한하는 토큰이 있다.
- Shared objects: 누구나 사용할 수 있는 공개 접근 objects이다. 이 objects에 저장된 데이터를 변경하려면 일반적으로 스마트 계약에서 규칙을 정의해야 한다.
Sui의 모든 ownership 유형은 객체 소유권 유형을 참조하라.
Access control
Identity 또는 role 기반 access control은 Solidity의 OpenZeppelin Ownable 및 AccessControl contracts를 통해 널리 사용된다.
Object ownership은 Sui에 내재되어 있으므로 contract functions에 대한 접근은 일반적으로 capability objects를 통해 제한된다.
이 objects는 사용자에게 발급되므로 특정 functions를 호출할 권한을 부여한다. 사용자가 함수가 기대하는 object를 소유하지 않으면 함수 호출은 실패한다.
여전히 address 기반 검사를 구현할 수 있다. 그러나 더 나은 보안을 위해 가능한 한 capability objects를 사용하는 것이 권장된다.
The Move Book에서 더 자세히 읽을 수 있다.
이 예시에서는 함수 호출 시 AdminCap object를 제시해야만 새 사용자를 생성할 수 있다.
/// 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) }
}
Mutating objects
Rust에서는 데이터 구조가 programs가 읽고 쓰는 별도의 account structures에 저장된다. Programs는 stateless이며 접근할 accounts를 미리 선언한다. 데이터를 변경하려면 적절한 account references가 포함된 transaction에 서명해야 하며 program은 명시적 검사를 통해 signer permissions를 검증한다.
Move에서는 데이터를 변경하는 로직이 contract에 정의되지만 데이터는 Move objects에 저장된다.
데이터를 변경하려면 objects의 소유자가 PTB를 사용해 contract functions를 호출해야 한다. 소유권 검사는 프로토콜 수준에서 수행되므로 서명자가 참조된 objects에 접근할 수 없으면 transactions는 실패한다.
Programmable transaction blocks
Rust에서 여러 program 호출의 결과를 함께 연결하려면 일반적으로 여러 개의 순차 transaction을 만들거나 program 내부에서 Cross-Program Invocations(CPIs)를 사용해야 한다. CPIs는 programs가 단일 transaction 안에서 다른 programs를 원자적으로 호출할 수 있게 하지만 깊이가 4단계로 제한되며 account 관리를 신중히 해야 한다. 클라이언트 측 transaction chaining은 각 transaction이 다음 것이 제출되기 전에 완료되어야 하므로 원자성 보장이 없다.
Move에서는 PTB가 이 문제를 해결한다. PTB는 빌더에게 런타임에 원자성 보장을 유지하면서 contract 호출을 함께 연결할 수 있는 능력을 제공한다. Sui PTB에는 최대 1,024개의 서로 다른 contract 호출 또는 다른 actions를 포함할 수 있다. PTB는 사실상 간단하면서도 표현력이 높고 강력하며 안전한 제한된 스크립팅 언어를 제공한다.
Sui의 빌더는 PTB를 활용해 그렇지 않으면 다루기 어려운 경험을 제공한다. 좋은 예는 최적의 가격으로 여러 DeFi 프로토콜에 걸쳐 토큰 스왑을 라우팅하는 DeFi aggregator이다. Sui에서 aggregator는 표시된 가격으로 transaction이 실행되거나 완전히 revert된다는 보장을 가진 단일 PTB를 사용한다. PTB는 가장 강력한 Sui 기능 중 하나이다. 경험상 Sui에서 가장 성공적인 빌더는 이 기능을 단지 transactions를 배치하는 방법으로 취급하지 않고 초기에 자주 활용하는 빌더이다.
PTB에 대한 자세한 내용은 프로그래머블 트랜잭션 블록 (PTB)를 참조하라.
More comparison
| Topic | 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)를 통한 오프체인 governance | 온체인 governance |
| Bridges | 지원된다 | 지원된다 |
| Network security (stake required for control) | 전체 stake의 66%(BFT requirement) | 전체 stake의 66% |
| Smart contract auditing | account model 복잡성, PDA patterns, CPI 취약성 때문에 포괄적인 감사를 요구한다 | 더 적은 감사를 필요로 하며 언어가 일부 역할을 수행한다(object model) |
| 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 logs로 인덱싱되며 custom parsing 또는 indexer가 필요하다 | sender, object ID, type, timestamp로 인덱싱된다 |
| Indexing | 상위 수준 transaction 데이터이며 custom indexers(Helius, Triton, Shyft)가 필요하다 | 상위 수준 transaction 데이터 + objects, coins, GraphQL RPC 지원 |
| Oracles | third party | third party |
| Network upgrade strategy | validators가 투표한 feature gates가 초과 정족수에 도달하면 활성화된다 | protocol flags와 framework upgrades를 validators가 투표한 뒤 활성화한다 |
| IDE | VSCode (Rust Analyzer) | VSCode (Move extension) |
| Transaction lifecycle | Transaction이 RPC에 제출되고 leaders에게 전파되며 block에 포함되고 Tower BFT를 사용해 validators가 투표한다. | transaction certificate(실행 보장)를 생성하기 위해 클라이언트에서 validators로 두 번 왕복하고 shared objects의 순서를 보장하기 위해 한 번 더 왕복한다. |
| Parallel execution | Sealevel runtime은 transactions의 account 접근이 겹치지 않을 때 병렬 실행을 가능하게 한다. Accounts는 스케줄링을 위해 미리 선언해야 한다. | 병렬 실행할 수 있는 transactions는 병렬로 실행된다. |
| Storage fees, storage rebates | rent-exempt accounts는 최소 잔액을 요구한다. 2021년 이후 rent collection이 없고 rebates도 없다. | 낮은 storage fees를 선불로 지불하며 objects를 파기하면 정리를 장려하기 위한 rebates가 있다. |
| Contract immutability | Programs는 배포 시 upgradeable 또는 immutable로 표시할 수 있다. | objects인 upgrade capabilities를 사용해 native mutable 및 immutable 지원을 제공한다. |
| Contract upgrading | native이며 upgradeable로 표시된 programs는 upgrade authority가 업그레이드할 수 있다. | native이며 upgrade capability가 중개한다. |
| Composability | Cross-Program Invocations(CPIs)는 programs가 transaction 안에서 다른 programs를 호출할 수 있게 한다. 깊이는 4단계로 제한된다. Transaction 경계 안에서는 원자적이다. | PTB를 사용해 하나 의 transaction 안에서 임의의 수의 functions를 호출한다. 한 호출의 출력을 받아 다른 호출의 입력으로 넘겨 조합한다. PTB당 최대 1,024개의 commands로 원자적 실행을 보장한다. |
| Token royalties | 직접적이지 않다. MPL Core 같은 프로토콜이나 Token22 같은 extensions를 통해 강제된다. | Kiosk와 transfer policies를 통해 체인에서 강제된다. |
| Block time and finality | ~400ms 블록 시간이며 ~12-13초 후 경제적 확정성을 가진다(Alpenglow 업그레이드 이전). | 독립 transactions는 sub-second finality를 가지며 shared objects는 Mysticeti로 ~390ms이다. |