0. CosmWasm 소개
CosmWasm은 코스모스 생태계에서의 스마트컨트랙트 플랫폼으로, 다양한 블록체인 네트워크에서 사용할 수 있으며, 웹어셈블리를 활용하여 스마트 컨트랙트를 실행한다. 즉, 코스모스 SDK 위에서 웹 어셈블리어 바이트코드를 실행할 수 있는 모듈이다. CosmWasm은 디지털 자산의 전송, 계약 체결, 탈중앙화된 애플리케이션 개발 등 다양한 블록체인 기반 비즈니스 모델을 구현하는 데 사용될 수 있다. 또한, 효율적인 비용 관리와 확장성을 제공하여 블록체인 네트워크의 성능을 향상시킨다는 장점을 가진다. 현재 코즘와즘을 활용하여 콘트랙트 실행환경을 구축한 대표적인 네트워크로는 테라, 오스모시스(테스트넷), 시크릿 네트워크, 주노 네트워크, 클리프넷(테스트넷) 등이 있다.
1. 타 서비스와의 비교
EVM(Ethereum Virtual Machine, 이더리움 가상머신)
이더리움의 강점이자 특징인 스마트 컨트랙트는 EVM을 통해 실현되는데, EVM의 가장 큰 역할 중 하나는 이더리움이 정의한 규칙에 따라 스마트 컨트랙트 코드를 실행하고 그 결과로 변화된 상태(state)를 업데이트하는 작업을 수행하는 것이다. 또한 EVM은 앞선 과정에서 코드 실행이 성공적으로 완료됐을 때만 상태를 변경하여 스마트 컨트랙트가 직접적으로 블록체인에 영향을 미치지 않도록 보호하는 샌드박스의 역할도 수행한다.
이러한 EVM과 CosmWasm을 보안, 성능 및 비용, Lock-in 이라는 세 가지 측면에 대해 비교하였다.
a. 보안
EVM과 스마트 컨트랙트 작성 언어인 Solidity는 구조상의 특징으로 인해 공격 벡터를 다수 가지고 있다. 최근 발생한 대규모 공격 사례인 Parity의 Multi-sig 해킹이나 CREAM 금융 해킹 사건은 라이브러리 계약과 프록시가 원인이 되어 발생하였다.
그런데 CosmWasm의 경우 설계상 재진입(Reentrancy) 취약점을 방지하고, “라이브러리 계약” 패턴이 아닌 계약을 마이그레이션 하기 때문에 Solidity에 존재 하는 대부분의 공격 클래스를 막을 수 있다.
라이브러리 계약 방식은 스마트 컨트랙트 개발 시 코드의 재사용성을 높이는 방법으로, 공통 기능이나 로직을 가진 스마트 컨트랙트 코드를 라이브러리로 작성하고, 다른 스마트 컨트랙트에서 이 라이브러리를 호출하여 사용한다. 반면 계약 마이그레이션 방식은 스마트 컨트랙트 업그레이드나 수정 시 이전 버전의 계약을 새로운 계약으로 대체하는 방식으로, 기존 스마트 컨트랙트의 상태와 로직을 새로운 계약으로 이전하고, 사용자나 기타 관련된 컨트랙트들이 변경사항에 대해 인식하고 상호작용이 가능하다.
b. 성능 및 비용
블록체인 개발자는 모든 프로젝트 코드를 섬세하게 검토하고 공격벡터를 제거하지만, 조건문이나 반복문의 사소한 오류로 인해 수천만달러의 손실이 순식간에 발생하곤 한다. 이는 Solidity 언어의 특성상 유닛 테스트가 어렵기 때문인데, 실제로 Compound는 최근 ‘<=‘ 논리연산자 대신 ‘<‘를 사용함으로인해 9천만달러의 손해를 보았다.
CosmWasm은 애초부터 여러 단계(유닛, 통합 및 풀스택)에서 최고 수준의 테스트 기능을 제공하여 이러한 부담을 줄였다.
이더리움이 갖는 또하나의 고질적인 문제인 가스비 부담과 낮은 확장성의 경우, CosmWasm을 사용하면 초당 수백 개의 트랜잭션을 가볍게 처리할 수 있으며 여러 연결된 체인에 배포되어 확장성을 향상시키는 동시에 비용 부담을 줄일 수 있다.
c. Lock-in
Lock-in 이란 기존 서비스보다 더 뛰어난 서비스가 나와도 이미 투자된 기회비용 등으로 인해 새로운 서비스로 옮기지 못하는 것, 즉 하나의 서비스에 고착화된 소비자들이 다른 곳으로 옮기기 힘든 현상을 뜻한다.
이러한 Lock-in 현상은 블록체인 산업에서도 찾아볼 수 있는데, 하나의 블록체인에 프로젝트를 배포하면 이후에 전환하기가 매우 까다롭기 때문이다. 이러한 문제는 다른 프로젝트와의 통합이 필요할 때 더욱 두드러진다.
그런데 기본적으로 Cosmos SDK 및 IBC를 기반으로 하는 CosmWasm은 프로젝트를 여러 체인에 걸쳐 조합하거나 다른 블록체인으로 마이그레이션 하는 기능을 지원한다.
Cosmos SDK (Software Development Kit)
코스모스 프로젝트의 핵심기술인 Cosmos SDK(Software Development Kit)는 복잡한 개발과정을 간단하게 해결하고 손쉬운 DApp 개발을 가능하게 하는 도구로, 개발자가 최소한의 복잡성으로 Tendermint 합의 알고리즘을 사용하여 블록체인을 구축할 수 있도록 한다.
이러한 Cosmos SDK와 비교하여 CosmWasm이 갖는 장점은 다음과 같다.
1) 독립형 체인이 필수적이지 않다
체인을 구축하고 유지하는 데에는 많은 간접비용이 발생하는데, Cosmos SDK를 통한 네트워크를 운영에는 여전히 강력한 검증자 커뮤니티를 유치하고 충분히 인센티브를 지급하는 등의 비용이 필요하다. 이는 시작 단계의 프로젝트들에게 큰 부담으로 다가올 수 있다.
이에 비해 CosmWasm을 사용하면 선택한 기존 블록체인에 간단한 과정만으로 배포가 가능하며, 필요시 자체 체인(또는 다른 체인)으로 마이그레이션할 수 있다. 이와 일맥상통하게 CosmWasm의 경우 Cosmos SDK와는 다르게 마이그레이션이 매우 용이하다는 장점이 있다.
2) API 측면에서의 장점
Cosmos SDK가 새로운 기능을 업데이트하는 동안 API도 서비스를 중단하게 되는데, 이 시간이 제법 길게 소요된다. 따라서 CosmWasm을 사용하면 보다 안정적인 API 이용이 가능하다.
또한 CosmWasm은 Cosmos SDK에 비해 개선된 스토리지 API를 제공한다.
2. 발전된 부분
Contract Migration
블록체인 플랫폼에서 스마트 계약을 업그레이드하는 과정이다. Ethereum에서 버그 수정이나 새로운 기능 추가를 위해 업그레이드 관련 어려움을 겪었고 이를 해결하기 위해 라이브러리 계약과 프록시 계약을 사용하였다. 그러나 Parity MultiSig 등의 버그가 나타났다.CosmWasm은 이러한 한계를 극복하기 위해 Contract Migration을 우선순위로 삼고 개발되었다. 계약을 인스턴스화할 때 선택적으로 관리자 필드를 설정할 수 있다. 관리자 필드를 비워 둔 경우 계약은 불변 상태를 유지하고 외부 계정이나 거버넌스 계약으로 관리자 필드를 설정한 경우 마이그레이션으로 돌아갈 수 있다. 이는 기존 상태를 보존하면서 최신 상태로 전환이 가능하도록 한다.Contract Migration은 3단계로 이루어진다. 첫번째, 업데이트할 계약의 최신 버전을 작성한다. 두번째. 인스턴스화하지 않고 새 코드를 업로드한다. 마지막으로, ‘MsgMigrateContract’ 전용 트랜잭션을 사용하여 기존 계약이 새 코드를 사용하도록 지정한다.상태 변경이나 필드 초기화를 해야 할 경우, 마이그레이션 메시지에 msg 필드를 전달하고, 새 코드의 ‘migrate’ 함수를 호출하여 마이그레이션 과정에서 필요한 마이그레이션 작업을 수행한다. ‘migrate’ 함수가 오류를 반환하면 트랜잭션이 중단되고 모든 상태 변경이 복원되며 마이그레이션 과정이 수행되지 않는다.
Storage Helpers
Cosmos SDK는 iterating over ranges를 포함한 다양한 데이터 접근을 제공하지만 중앙 KVStore 추상화에서 raw byte를 노출하고 있으며 이를 처리할 공통적인 추상화가 없다. CosmWasm은 Wasm의 경계에서 사용하는 raw byte와 유사한 Storage 인터페이스를 정의한다. 그러나 이러한 방법 대신 추상화와 상태 저장소 작업을 간소화하기 위해 다음과 같은 Storage Helper를 제공한다. ‘cosmwasm-storage’ 라이브러리는 Singleton 및 Bucket과 같은 유형을 제공하고 값들의 직렬화의 복잡성을 숨긴다. ‘cw-storage-plus’는 Item과 Map을 일반적인 기본 도구로 제공하여 저장된 것이다. 이 기능은 여러가지 유형(i.e. 튜플)을 키로 사용 가능하며 액세스하기 쉬운 API를 제공한다. 두번째로 IndexedMap은 Map에서 자동으로 보조 인덱스를 저장하고 쿼리할 수 있는 방법을 제공한다. 이처럼 함수를 인덱스로 정의하고 구성하는 것은 복잡하지만 일반적으로 저장할 때 모든 항목에 대해 인덱스를 정의할 수 있고 이를 기반으로 저장소 로직 없이 쿼리를 수행하거나 필요할 때 업데이트가 가능하다.
Submessage
계약에서 에러로 인해 리턴된 메시지는 Submessage를 사용하여 처리를 할 수 있다. Contract에서 를 통해 다른 계약의 실행 결과를 처리할 수 있습니다.두 가지 경우가 있다. 첫 번째, 다른 계약을 인스턴스화한 다음 방금 생성된 계약의 주소를 가져오는 것이다. 계약이 인스턴스화될 때, x/wasm은 새로운 계약 주소를 포함하는 표준 이벤트 instantiate._contract_addr를 생성시키고 데이터 필드에는 새 주소와 계약에서 반환된 데이터가 포함된 protobuf 인코딩 메시지가 포함된다. 이 기능은 Tgrade의 TFi AMM Factory에서 새로운 트랜잭션 쌍을 생성하고 방금 생성된 계약의 주소를 결정해야 할 때 사용된다. Cw-plus에 추가된 helper를 통해 WasmMsg::Instantiate에서 반환된 응답 및 WasmMsg::Execute에서 반환된 데이터를 구문 분석할 수 있다.두 번째, 다른 메시지가 실패될 때 주요 메시지의 실패하지 않도록 하는 것이다. 예를 들어 IBC에서 패킷이 거부된 경우 핸들러는 오류를 반환하지 않고 오류 패킷과 확인 데이터를 반환하여 다른 쪽에서 처리할 수 있도록 한다. cw20-icw20 구축 과정에서 실패할 수 있는 Cw20::Transfer 메시지를 처리하며 트랜잭션이 실패하지 않도록 하기 위해서 SubMsg로 sendAmount 액션을 실행한다. SubMsg::reply_on_error를 사용하여 메시지가 실패하면 콜백을 받을 수 있도록 하고 응답 핸들러에서는 실패한 ack 패킷을 포함하는 새로운 데이터 필드를 작성하여 원래 보낸 사람에게 중계될 수 있도록 처리한다. 이 과정에서 트랜잭션은 오류를 반환하지 않으며 Submessage의 상태(i.e. cw20 컨트랙트)가 반환되지만 주요 메시지(i.e. IBC, cw20-ics20의 상태 변경)는 되돌아가지 않는다.
3. Architecture
Smart Query
먼저 Smart Query에 대해 설명하기 전에 블록체인 기반 smart contract의 인터페이스에 대해 알아보자. 공개된 인터페이스는 두 가지가 있는데, 바로 Transaction을 통한 인터페이스와 Query이다.
a. Transaction을 통한 인터페이스
Transaction은 smart contract의 상태를 쓰기, 삭제하기, 수정하기로 변경한다. transaction 데이터베이스에 저장된다.
b. Query를 통한 인터페이스
Read-only이다. 다시 말해, smart contract의 상태를 읽기만 한다. transaction에 기록이 남지 않는다.
b.를 확장하여 Smart Query에 대해 알아보자. Smart Query는 wasm contract에 의해 실행되며, smart contract에 대해 읽을 때 암호화된 유형을 사용하여 직접 주어진 key-value 쌍을 읽을 수 있다. smart contract가 transaction의 일부로 query를 생성할 때 query entry point는 데이터베이스에 대해 읽기 권한만 가지며, 다른 계약을 호출 할 수 없다. 이로 인해 가질 수 있는 장점에 대해서는 뒤에서 더 자세히 살펴보겠다.
보안
Solidity와 EVM은 보안에 매우 취약한 아키텍처를 가지고 있다. 보안성을 높이기 위해 재진입을 막는 reentrancy guards를 사용해도, 그리 큰 도움은 되지 못한다. 이의 대표적인 예가 동일한 state를 공유하는 여러 스마트 컨트랙트가 업데이트 될 때 발생하는 Cross-contract Reentrancy 문제이다. 이에 반해 CosmWasm은 보안성이 뛰어나다. CosmWasm 아키텍처는 이더리움에서 일어날 수 있는 거의 모든 리스크를 방지한다. 이게 어떻게 가능할까? CosmWasm의 창시자이자 CEO인 Ethan Frey의 설명 중 크게 두 가지를 소개하겠다.
a. 행위자 모델
이더리움에 가장 치명적인 공격 중 하나는 Reentrancy Attack(재진입 공격)이다. 재진입은 smart contract에서 신뢰할 수 없는 외부 contract를 호출하고, 그 외부 contract가 smart contract를 다시 호출하는 과정이 계속 반복되는 과정이다. 가장 간단하게는 아래 그림처럼 사용자가 예치한 자금에서 계약금을 반복적으로 인출해오는 것이다.
CosmWasm은 행위자 모델을 통해 이러한 공격 가능성을 차단했다. 행위자 모델은 smart contract의 실행 주체이다.
contract를 호출하는 방법은 크게 두 가지로, contract 내부 상태에 읽기 권한만 가지는 query 코드와 읽기와 쓰기가 모두 가능한 실행 코드로 나뉜다. query의 경우 별도의 가스비를 지불하지 않지만 실행의 경우는 내부 상태를 바꾸는 것이기 때문에 가스비를 지불해야 한다. 이렇게 실행과 query를 명확히 구분 두어 재진입 문제를 해결할 수 있다.
b. 블록 해시와 tx.origin 노출X
CosmWasm에서는 블록 해시과 tx.origin 값을 노출하지 않는다. 이때 tx.origin은 transaction을 보낸 계좌 주소를 반환하는 전역 변수로, 자주 공격의 대상이 되는 API 필드이다. 또 이더리움에서 과거에 블록 해시를 이용한 공격이 발생했기 때문에 CosmWasm에서는 둘다 공개하지 않기로 결정했다.
Reference:
https://medium.com/cosmwasm/cosmwasm-for-ctos-f1ffa19cccb8
https://medium.com/decipher-media/2022-01-04-디사이퍼-cosmwasm-특별세션-2부-cosmwasm의-강점-및-로드맵-9e96113c52e5
https://cosmwasm.com/home/about/
https://medium.com/cosmwasm/cosmwasm-for-ctos-i-the-architecture-59a3e52d9b9c
https://www.geeksforgeeks.org/reentrancy-attack-in-smart-contracts/
https://velog.io/@harvey/Cosmos-SDK-CosmWasm-소개-1
https://medium.com/cosmwasm/cosmwasmclient-part-1-reading-e0313472a158
https://www.parametacorp.com/blog/2017/04/04/스마트-컨트랙트smart-contract-개요-2/
https://velog.io/@devjeenie/블록체인Block-Chain-시리즈-4.-스마트-컨트랙트Smart-Contract
https://book.cosmwasm.com/actor-model.html
https://medium.com/immunefi/the-ultimate-guide-to-reentrancy-19526f105ac
