시작하기 앞서
최근 두 가지 Solana와 Aptos 의 Blockchain 의 탈중앙화 NFT Marketplace를 둘 다 직접 코드로 제작해봤고, 두 가지의 확연한 DApp 개발 스타일의 차이를 보며, 이에 대한 경험을 적어보고자 합니다.
Aptos / Soalan 모두 빠른 fastest blockchain 을 추구하는 훌륭한 블록체인 infrastructure 이다. 성능에 초점을 둔 빠른 블록체인이기 때문에 Application level의 DApp이 활용되기에는 최적의 블록체인이라고 생각합니다. 둘다 Rust 에 뿌리를 두고, 블록체인 기술을 구현했다는 점에서는 공통점을 지니고 있습니다. 이번 글은 Solana / Aptos DApp 개발자로서의 각각의 장단점은 적어보고자 한다.
1. Rust의 활용 차이
Rust 의 low-level 언어의 performance 장점은 두 블록체인 모두 지니고 있으며, Rust의 프로그래밍 언어의 추상화의 장점은 Move 언어와 Solana DApp 잘 녹여져 있다. Move 언어에는 Solana DApp 에는 없는 간결함을 지니고 있어서, DApp 의 빠른 개발이 가능하고, Solana DApp의 byte level 의 memory 관리 코드들이 없어서 복잡한 코드구성을 피할 수 있습니다. 개인적으로는 앱토스의 Move 는 DApp 개발에 있어서 더 가독성있고, 생성성을 지닌 언어라고 느낍니다.
Solana 는 DApp 은 Account 모델, PDA , ATA 등 다양한 추상화 개념때문에 처음 개발을 시작하는데 있어서, 러닝커브가 심한 편입니다. 훌륭한 디자인이라고 생각이 들지만, 범용성 측면에서는 Smart contract 언어로서 활용되기에 한계가 보이는 느낌이었습니다. Soalana DApp은 Rust 에 대한 장벽 + Solana programming model 의 추상화 개념 + byte level 의 메모리 관리 등을 모두 이해해야 원할한 DApp 개발이 가능하여, 개발자들이 많은 어려움을 느낄 것이라고 생각됩니다.
2. DApp 언어 차이
Solana 는 Rust 를 사용하고, Aptos 는 Move라는 스마트컨트랙트 언어를 사용합니다. 이더리움의 EVM 처럼 Move 도 MoveVM 위에서 작동되는 언어입니다. Move 언어의 대표적인 특징으로는 scarcity(희소성) 과 access control 이 있습니다. Scarcity 의 특징 덕에 move 의 구조체는 복제되지 않으며, 이는 digital asset 정의 및 활용에 최적화 되어 있는 느낌입니다. move에서는 바이트코드 레벨에 있는 구조체만 복제가 가능하다고 합니다.
Solana DApp 은 Account Model 기반의 언어입니다. Account 기반으로 state 를 관리하고, 트랜잭션 사이에서 이를 활용합니다. PDA, ATA 등 솔라나의 데이터 구조체는 Account 등의 데이터 모델을 주로 활용하는데, 처음 Solana DApp 을 개발하는데 있어서, Account 에 대한 활용을 위해서는 추상화 모델을 정확하게 이해할 필요가 있습니다. 또한 byte 단위로 메모리를 관리하는 형태의 구조체와 rent 개념 등이 추상화되어 구현되어 있어서, DApp 개발하는데 러닝커브가 소요되는 편입니다.
아래 내용은 Solana NFT marketplace 의 Rust DApp 코드와 javascript front-end 코드입니다.
Move 의 nft marketplace 는 DApp code와 javascript 코드는 아래와 같습니다.
얼핏보면 둘다 복잡해보일 수 있지만, 코드를 모두 작성해본 경험에서 같은 목적의 NFT marketplace 코드를 작성하는데 move로 작성된 smart contract 와 javascript front-end 코드가 더 직관적이고, 2배 정도 빠른 생산성을 경험했습니다.
향후 코드를 관리하는데 있어서도, 이런 점은 장점으로 작용해서 더 수월한 코드유지보수 또한 가능했습니다.
코드량 차이 또한 Solana 의 DApp이 Move 의 DApp 더 많았으며, 복잡한 형태의 구조를 띄고 있어서, 관리 또한 쉽지 않았습니다.
3. Struct 문법 비교와 활용성 차이
Solana / Move 의 언어를 살펴보면, state 관련 데이터를 위와 같은 형태를 띕니다. Solana 같은 경우, 향후 업데이트를 위해서 extra_space 를 주고, 차후 확장하는 형태의 데이터에 대한 공간을 미리 확보해 두는 경우가 다소 있습니다. 반면, Move 의 경우 strict 한 형태로 구조체를 잡고 있으며, 해당 Move 의 struct가 변경되면, 다시 재배포해야 되는 형태를 띕니다. Struct 의 데이터의 구조가 변화하지않으면, 기존 contract 를 업그레이드 할 수 있다는 점은 두 언어가 같습니다. Solana 의 경우, 차후 컨트랙트의 업데이트를 위해서 미리 공간을 확보해두는 패턴을 두는 반면, Move에서는 그런 부분을 지원하지는 않습니다.
4. Gas Fee / 트랜잭션 비용
Solana DApp의 경우, 블록체인 위에 rent exemption 을 위에 두어야 되는 Solana 의 금액이 보통 80만원에서 100만원 내외의 Solana를 하나의 DApp 당 예치해야 되어야 합니다. 물론 해당 DApp을 내리게 되면, 금액을 모두 회수할 수 있지만 타 DApp에 대비해서 이런 비용은 부담되는 금액인 것은 사실입니다.
반면, Aptos Move 의 경우 배포 이후 추가적인 비용이 발생하지 않습니다. 배포 비용 또한 매우 저렴합니다. 최근 배포한 Aptos NFT Marketplace 코드의 경우, 240원 내외의 비용이 발생했습니다. 솔라나에 비하면 매우 저렴하게 DApp을 배포할 수 있었습니다.
5. Hierarchy 구조의 DApp
Solana 생태계의 경우, 하나의 DApp 배포 후, 배포한 DApp 의 hierarchy를 두는 구조를 곧잘 활용합니다.
이렇게 되면 누군가 배포한 DApp의 이름이나 설정값을 변경하여, 자신의 DApp을 해당 DApp 의 하위 DApp으로 배포할 수 있는 구조를 띕니다. 특정 DApp의 하위 DApp을 두면 상위 rent exemption을 아껴서 특정 DApp을 빠르게 배포하고 활용할 수 있습니다. NFT marketplace 나 raffle, staking 등 다양한 프로그램을 하위 DApp을 배포할 수 있는 형태로 제공하며, 이를 활용하면 타인의 DApp을 저렴하게 배포하여, 나만의 DApp을 으로 만들어 활용할 수 있습니다. Solana 에서는 programId만 알면, 하위 DApp 을 구현 없이도 쉽게 만들어서 사용할 수 있다는 장점이 있습니다.
Move 생태계에서는 이러한 형태의 DApp 형태는 아직 보편적이지 않지만, 이런 방법으로도 구조체를 잡아서 DApp을 설계하는 것은 어렵지 않았습니다. 저희 NFT marketplace 및 DApp의 구조는 모두 hierarchy구조를 띄면서 개발했습니다. Solana DApp 개발에 익숙하다 보니, 자연스럽게 이런 구조로 처음 DApp을 습관적으로 만들게 되었네요. 이런 구조로 DApp을 만드는 것은 어렵지 않은 것 같습니다.
이런 구조로 제작해두면, 이름만 바꿔서 다양한 NFT marketplace 를 이미 배포한 Smart contract 상에서 만들고, 자신만의 NFT marketplace 를 운영할 수 있습니다. 이런 생태계가 보편화 되지 않는 것은 아마 Gas 비용이 Solana 대비 저렴하기 때문인 것 같습니다.
5. Move 의 중앙에서 만드는 NFT / Token Protocol 구조
Solana 나 ethereum 생태계와 다르게 Aptos 에서는 Move 에 대한 NFT / Token contract를 aptos-core 에 포함하여, 구현체와 함께 제공하고 있습니다. 이 Token contract(https://github.com/aptos-labs/aptos-core/blob/main/aptos-move/framework/aptos-token/sources/token.move) 덕분에 혼란스럽게 개별 interface 상의 token 구조를 각자 구현하는 일이 없습니다. 또한 token 컨트랙트에 대한 해킹 걱정도 core 에서 제공해주는 구현체 덕분에 덜 신경써도 되는 구조를 가지게 됩니다.
다만, 자유로운 DApp 생태계 구성에 있어서 중앙에서 정해주는 token contract 는 기능을 확장하는 서비스를 구상하는데 있어서 제약이 될 수 있습니다. 초기 token 컨트랙 버전에 없던 기능이 나중에 추가되거나 하는 경우에는 관련 업데이트를 주시하여, 개발하여야 하며, 이런 점에 대한 업데이트를 지속적으로 주시하여야 되는 점은 의외로 불편할 수 있다는 생각이 들었습니다.
반면, Solana 의 경우 NFT 생태계 커뮤니티에서 정하는 프로토콜을 따라가는 방향입니다. 이더리움의 경우, protocol에 대한 인터페이스 정의만하고, 구현체를 제공하거나 정하진 않습니다.
솔라나 같은 경우 royalty 문제로 candy machine 과 NFT 거래소 간의 구현체를 서로 강제하면서 다툼도 있었는데, 이렇게 중앙에서 정해주는 aptos move 의 경우, 이런 혼란을 피할 수 있어서 좋지 않을까 싶었습니다.
댓글