A Study on Security Vulnerabilities and Lightweight Protection Mechanisms in Solana CPI-Based Smart Contracts

Solana CPI 기반의 스마트 컨트랙트 보안 취약점 및 경량 보안 기법에 관한 연구

Abstract

This paper presents an empirical analysis of security vulnerabilities in Solana smart contracts, focusing on the Cross-Program Invocation (CPI) mechanism. VRust, a vulnerability detection framework for Solana, identifies issues related to missing runtime account checks. Based on this, we selected four critical vulnerabilities that cannot be fully prevented by the Anchor framework. Our experiments show that two of these-Missing Signer Check and Missing Owner Check-remain exploitable even with Anchor declarations, allowing unauthorized state changes. In contrast, Unauthorized Writable Access and Account Reinitialization were successfully mitigated by Anchor's checks. To address this gap, we propose SecureCPIGuard, a lightweight module that performs context-based account verification before CPI execution. Our results demonstrate that SecureCPIGuard effectively blocks unauthorized access with minimal performance impact. This highlights the need for runtime verification and offers a practical method to secure CPI-based smart contracts.

본 논문은 Solana 스마트 컨트랙트에서 Cross-Program Invocation(CPI) 구조가 갖는 보안취약점을 실험적으로 분석하고, 이를 방지하기 위한 경량 보안 알고리즘 SecureCPIGuard를 제안한다. VRust 연구에서 제시된 8가지 Solana 취약점 유형 중 Anchor 프레임워크로 구조적으로 방어하기 어려운 4가지를 중심으로 공격 시나리오를 구현하였다. 그 결과, Missing Signer Check와 Missing Owner Check는 Anchor만으로는 차단되지 않고 상태 변경이 가능함을 확인하였다. 반면, Unauthorized Writable Access와 Account Reinitialization은 Anchor 구조 내에서 방지 가능하였다. 이를 바탕으로 실행 시점에서 context 기반 계정 속성 검증을 수행하는 SecureCPIGuard를 설계하고, 트랜잭션 처리 시간과 보안성 차이를 실험적으로 분석하였다. 본 제안 기법은 Anchor 기반 검증의 한계를 보완하며, 성능을 유지하면서 실효성 있는 보안을 구현할 수 있음을 확인하였다.

I. 서론

Solana는 고성능 블록체인 플랫폼으로, 병렬 처리 기반의 Sealevel 실행 엔진과 Proof of History(PoH) 기반 합의 알고리즘을 통해 높은 트랜잭션 처리량을 제공한다[1]. Sealevel은 트랜잭션 간 계정 의존성을 분석하여 충돌이 없는 실행을 병렬화하고, 짧은 블록 생성 주기를 유지함으로써 속도와 확장성을 동시에 확보한다. 이를 가능하게 하는 핵심 구조 중 하나가 프로그램 간 직접 호출을 허용하는 Cross-Program Invocation(CPI) 구조이다. CPI는 기능 모듈화를 통해 복잡한 스마트컨트랙트 구현을 가능하게 하며, Solana 생태계의 높은 처리 효율성과 개발 유연성에 기여해왔다.

이러한 구조적 강점 덕분에 Solana는 현존 블록체인 중 최고 수준의 처리량을 제공하며[2][3], DeFi·NFT·GameFi 등 다양한 서비스 분야에서 빠르게 채택되고 있다[4]. 그러나 고성능과 병렬 실행 구조는 외부에서 context를 조작할 수 있는 CPI 설계 특성과 결합하여 새로운 유형의 보안 위협을 만들어낸다. 특히 Solana의 병렬 실행·CPI 환경은 기존 순차 실행 기반 블록체인에서는 드물었던 고유 취약점을 유발할 수 있으며, 이를 악용하면 심각한 피해로 이어질 수 있다.

그럼에도 불구하고 기존 스마트컨트랙트 보안 연구는 대부분 Ethereum 중심으로 진행되어 왔다. 이로 인해 Solana의 병렬 처리·CPI 구조를 전제로 한 실증적 취약점 분석과 방어 기법 연구는 여전히 부족하다. 본 연구는 이러한 기술적 특성과 연구 공백을 고려하여 Solana를 주요 분석 대상으로 삼고, 구조적 취약점의 재현과 이를 방어하기 위한 실용적인 대안을 제시한다.

그러나 CPI 구조는 호출자 프로그램이 context를 구성하고 계정 권한(signer, owner, writable 등)을 설정하는 특성상, 호출된 프로그램이 이를 검증하지 않으면 실행 시점 검증이 생략되는 구조적 취약점을 갖는다[5]. 이러한 문제는 기존 분석 도구로 코드 수준 탐지가 가능하지만, Missing Signer Check나 Missing Owner Check와 같이 Anchor 선언만으로는 방어가 어려운 항목들은 실제 실행 환경에서 악용 가능성이 남아 있다[6].

이와 같은 구조적 취약점은 Ethereum과의 비교를 통해 더욱 분명해진다. Ethereum은 단일 스레드 기반의 순차 실행 모델을 채택하며, 스마트컨트랙트 내부에서 msg.sender, require, modifier 등을 이용하여 실행 조건을 명시적으로 정의한다[10][11]. 즉, 보안 검증 책임이 각 컨트랙트 내부에 집중되어 있으며, 실행 흐름은 비교적 명확하다. 반면 Solana에서는 트랜잭션 실행 전 계정 배열(AccountInfo[])이 외부에서 구성되고, 각 프로그램은 이를 받아 context로 해석하여 처리한다. 특히 Anchor 프레임워크는 #[account], has_one, mut 등의 속성 선언을 통해 검증 코드를 자동 생성하지만, 해당 검증은 context가 내부에서 생성될 때만 유효하며, 외부 CPI 호출 시에는 구조적으로 우회가 가능하다.

본 논문은 이러한 배경을 바탕으로, Solana CPI 구조에서 발생 가능한 보안 위협을 실험적으로 분석하고, Anchor 프레임워크만으로는 방어할 수 없는 공격 시나리오를 재현하였다. 이를 해결하기 위해 실행 시점에서 context 기반으로 계정 속성을 동적으로 검증하는 경량 보안 모듈 SecureCPIGuard를 제안한다. 본 모듈은 Anchor 구조와 호환성을 유지하면서도 signer, owner, writable 속성에 대한 정책 기반 검증을 수행하며, 조건 불일치 시 오류 메시지를 반환하고 실행을 차단한다. 또한 SecureCPIGuard 적용 전후를 비교 실험하여 보안 효과와 성능 오버헤드를 분석하고, 트랜잭션 처리 시간·오류 메시지·검증 성공률을 통해 실질적이고 확장 가능한 보안 강화 수단임을 입증하였다.

본 논문의 구성은 다음과 같다. 2장에서는 관련 연구를, 3장에서는 제안 기법을, 4장에서는 실험 결과 및 성능 분석을, 5장에서는 결론을 제시한다.

II. 관련 연구(Related Work)

[1] Wu et al.의 Exploring Vulnerabilities and Concerns in Solana Smart Contracts는 Solana의 계정 모델과 CPI(Cross-Program Invocation) 구조에서 발생 가능한 권한 검증 부재 문제를 분석하고, signer·owner 속성 위조를 통한 상태 변경 가능성을 구체적으로 제시하였다. 연구에서는 CPI 호출 시 발생할 수 있는 권한 검증 생략, 임의 계정 삽입, writable 플래그 오용 등의 공격 시나리오를 상세히 설명하였다. 이러한 분석은 SecureCPIGuard의 signer·owner·writable 속성 검증 로직을 설계하는 직접적 근거가 되었으며, CPI 기반 호출 환경에서 실행 시점 검증의 필요성을 강조하는 논리적 기반을 제공하였다.

[5] Madhwal et al.의 Portable Blockchain for System Testing of Solana Smart Contracts는 재현 가능한 로컬 테스트 환경을 통해 Solana 스마트컨트랙트의 반복 실험을 지원하는 프레임워크를 제안하였다. 이 환경은 네트워크 지연, 블록 생성 속도, 계정 상태 등을 제어하여 동일 조건에서의 성능 비교가 가능하며, 오프라인 상태에서도 실험을 수행할 수 있다. 특히, Wu et al.의 연구에서 제기된 취약점 재현을 위해 안정적이고 변동성이 없는 실험 환경이 필수적이므로, 본 연구에서는 이러한 환경 개념을 차용하여 SecureCPIGuard 적용 전후의 성능 비교 실험을 네트워크 변동성 없이 수행함으로써 실험 데이터의 일관성과 신뢰성을 확보하였다.

[6] Cui et al.의 VRust는 Solana 스마트컨트랙트의 구조적 보안 취약점을 자동 탐지하기 위해 개발된 정적 분석 도구로, 소스 코드 및 BPF(Bytecode) 수준에서 프로그램을 분석하여 총 8가지 취약점 유형을 정의하고 탐지 방법을 제시하였다. 분석 결과, Unauthorized Writable Access와 Account Reinitialization과 같은 일부 취약점은 Anchor의 선언 기반 검증만으로도 방어가 가능하나, Missing Signer Check와 Missing Owner Check는 실행 시점에서 계정 속성을 직접 검증하지 않는 한 차단이 어렵다는 구조적 한계가 확인되었다. 특히 CPI 호출 환경에서는 호출자가 context를 임의로 조작할 수 있어, 위조된 signer·owner 속성을 가진 계정이 호출 대상 프로그램으로 전달될 가능성이 존재한다. 본 연구에서는 이러한 분석 결과를 토대로 Anchor 기반 방어로는 한계가 있는 네 가지 취약점을 실험 대상으로 선정하고, SecureCPIGuard를 통해 해당 취약점의 실행 시점 차단 가능성을 검증하였다.

[7] Kim et al.의 SolaSim은 프로그램 표현(Program Representation)에 기반한 코드 유사도 분석 기법을 적용하여, Solana 스마트컨트랙트의 잠재적 보안 위협을 식별하는 도구이다. 이 기법은 프로그램의 추상 구문 트리(Abstract Syntax Tree, AST)와 제어 흐름 그래프(Control Flow Graph, CFG)를 이용하여 코드 간 유사성을 계산하고, 동일하거나 구조적으로 유사한 코드 재사용 시 기존 보안 결함이 함께 복제될 가능성을 식별한다. 이는 VRust에서 제시된 취약점이 특정 코드 패턴과 결합되어 반복적으로 나타날 수 있음을 시사하며, 재사용되는 코드에도 실행 시점 검증 모듈을 적용해야 함을 강조한다. 본 연구에서는 이러한 결과를 근거로 SecureCPIGuard의 범용성과 코드베이스 간 확장성을 검토하였다.

[8] Nishikawa et al.의 Fuzz on the Beach는 퍼징(fuzzing) 기법을 활용하여 Solana 스마트컨트랙트의 동적 오류와 보안 결함을 탐지하는 방안을 제시하였다. 본 연구는 무작위 및 변형 입력 데이터를 자동 생성하여 프로그램을 반복 실행함으로써, 예상치 못한 상태 변화를 유발하는 취약점을 탐지하였다. 특히 계정 검증 로직이 불충분할 경우, 비의도적 입력만으로도 취약점이 노출될 수 있음을 실험적으로 입증하였다. 이는 Kim et al.의 연구에서 지적한 구조적 결함이 동적 환경에서도 쉽게 노출될 수 있음을 보여주며, 악의적 공격뿐 아니라 정상 범위 외 입력에도 대응할 수 있는 실행 시점 검증 모듈의 필요성을 뒷받침한다. 본 연구에서는 이를 SecureCPIGuard 설계 시 반영하였다.

[9] Kashyap et al.의 Defying the Odds: Solana’s Unexpected Resilience in Spite of the FTX Collapse는 Solana 네트워크가 외부 충격(FTX 사태) 이후에도 안정적인 성능과 처리량을 유지할 수 있었던 구조적 요인을 분석한다. 이 연구는 합의 메커니즘, 네트워크 최적화, 트랜잭션 처리 구조 등 성능 회복과 확장성 유지에 기여하는 요소를 실증적으로 제시하였다. 이러한 결과는 보안 모듈 설계 시 성능 오버헤드 최소화와 네트워크 안정성 유지가 병행되어야 함을 강조하며, 본 논문에서 SecureCPIGuard의 경량화 설계 방향을 뒷받침하는 근거를 제공하였다.

III. 제안 기법

3.1 시스템 구성도 및 공격 흐름 개요

Solana 스마트컨트랙트의 트랜잭션 실행 구조는 사용자로부터 제출된 트랜잭션과 함께 전달되는 계정 배열(AccountInfo[])에 기반하여 작동하며, 프로그램은 이 배열을 통해 상태 계정, 권한 계정 등의 정보를 입력받는다. Anchor 프레임워크는 이러한 계정 배열을 context 구조체로 자동 매핑하고, 선언된 조건(signer, has_one, mut 등)에 따라 계정 속성을 사전에 검증함으로써 보안성을 확보한다. 그러나 CPI을 통해 프로그램이 호출되는 경우, 호출자는 context를 직접 구성하여 외부 프로그램에 전달할 수 있으며, 이 과정에서 계정의 signer 여부나 owner 일치 여부는 Anchor 구조 내에서 자동 검증되지 않는다.

본 논문에서는 이러한 구조적 취약점을 실험적으로 분석하기 위해, attacker 프로그램이 외부에서 cpi-test 프로그램을 CPI 방식으로 호출하고, signer가 아닌 가짜 계정(fake_signer)을 context의 signer 필드에 삽입하는 공격 시나리오를 구성하였다. 이때 cpi-test 프로그램은 Anchor 선언 구조를 기반으로 context를 해석하지만, 해당 context는 외부에서 임의로 구성된 것으로, 선언된 조건과 무관하게 트랜잭션 실행이 가능하다. Anchor의 context 구조는 #[derive(Accounts)] 선언을 통해 구조체 매핑만 수행하며, 실제 실행 시점에서 계정의 signer 여부를 확인하는 검증 로직은 존재하지 않기 때문에, 호출자가 context를 조작한 경우에도 프로그램은 이를 정상 입력으로 인식하고 상태 변경을 수행할 수 있다.

[Fig. 1]은 위와 같은 CPI 기반 공격 흐름을 시각화한 것이다. 사용자는 attacker 프로그램을 통해 트랜잭션을 제출하고, attacker는 fake_signer 계정을 포함하는 context를 직접 구성하여 cpi-test 프로그램을 호출한다. cpi-test는 이 context를 Anchor 구조체로 받아들인 후, 실행 시점의 서명자 검증 없이 함수 실행을 진행하며, 결과적으로 상태 계정(data_account)의 값을 변경하거나 의도된 공격을 수행하게 된다.

Fig. 1. Execution flow of SecureCPIGuard’s policy-based account validation

3.2 Anchor 기반 함수 구조와 보안 제약 요약

Solana의 Anchor 프레임워크는 각 함수에 필요한 계정을 #[derive(Accounts)] 매크로 기반 구조체로 선언하고, signer, has_one, mut 등의 어트리뷰트를 통해 계정 조건을 선언적으로 지정한다. 이러한 구조는 함수 호출 시 계정 조건을 자동 검증하도록 설계되어 있으며, 개발자에게 높은 생산성과 보안 유연성을 제공한다. 그러나 CPI을 통해 호출되는 함수는 context 구조체를 외부에서 조작하여 전달할 수 있기 때문에, Anchor의 선언 기반 조건은 실행 시점에서 무력화될 수 있다. 본 연구에서는 이러한 구조적 한계를 확인하기 위해 cpi-test 프로그램 내에 서로 다른 보안 수준을 가진 네 가지 함수를 구현하였다

initialize 함수는 계정 생성 및 권한 설정을 위한 함수로, init, payer, space, signer 조건이 모두 선언되어 있어 가장 강력한 보안 조건을 갖는다. update_value 함수는 상태 변경을 수행하며, data_account와 authority 간의 has_one 관계 및 signer 검증을 선언함으로써 정상적인 호출만을 허용한다. unsafe_write 함수는 authority 계정의 타입을 AccountInfo로 선언하고, Anchor의 CHECK 주석을 통해 signer 검증을 생략하였다. 이로 인해 외부 프로그램이 signer가 아닌 계정을 삽입하더라도 함수 실행이 가능하다. unsafe_update 함수는 모든 계정을 AccountInfo로 받아들이며, 어떤 선언 조건도 존재하지 않는다. 이 함수는 선언 기반 보안 검증이 완전히 제거된 상태에서 상태 변경이 가능한지를 실험하기 위해 사용되었다.

이러한 함수 구조의 차이는 [Table 1]에 요약되어 있다.

Table 1. Comparison of Anchor context structures

※ ✓: constraint enforced, ✗: constraint omitted, 'CHECK': Anchor macro used to explicitly skip validation

3.3 SecureCPIGuard 모듈 설계 및 동작 구조

Solana의 CPI 구조는 외부 프로그램이 context 구조체를 조작하여 임의의 계정을 삽입할 수 있는 설계 특성을 가지며, Anchor 프레임워크의 선언 기반 보안 모델은 이러한 상황에서 실행 시점 검증을 강제하지 못하는 구조적 한계를 내포하고 있다. 이를 보완하기 위해 본 논문에서는 SecureCPIGuard라는 경량 보안 모듈을 설계하였다. SecureCPIGuard는 Anchor의 기존 구조를 유지하면서도, 프로그램이 실행되는 시점에 context로 전달된 각 계정의 속성을 직접 확인하고, signer, owner, writable 조건의 만족 여부를 판단함으로써 CPI 호출 경로에서 발생 가능한 보안 우회를 차단한다. 이 모듈은 Anchor 구조체 내부에서 자동 생성되는 선언 기반 검증과는 달리, 실행 시점(runtime)에서 작동하는 구조적 검증 계층이다. SecureCPIGuard는 세 가지 핵심 속성을 기준으로 계정의 유효성을 검증한다. Signer 검증: .is_signer 플래그를 통해 계정이 실제 서명자인지 확인, Owner 검증: .owner 필드가 현재 실행 중인 프로그램 ID와 일치하는지 확인, Writable 검증: .is_writable 속성을 통해 계정이 상태 변경이 가능한지 확인한다. 이러한 검증은 사전에 정의된 정책 구조체(Policy Struct)와 실행 중 context로 전달된 계정 정보를 1:1로 매칭하여 이루어진다. 각 계정은 해당 policy와 비교되어 조건을 충족하지 않으면 즉시 함수 실행을 차단하고, 사용자 정의 오류를 반환한다.

[Fig. 2]는 secure_cpi_guard::default_verify_update(&ctx)? 호출 시 내부에서 수행되는 검증 절차를 보여준다. 이 함수는 전달받은 context 내 모든 계정(account)에 대해 대응되는 정책(policy)과 비교 검증을 수행하며, signer, owner, writable 조건이 불일치하는 경우 즉시 사용자 정의 오류를 반환한다.

Fig. 2. Runtime Account Validation Logic in SecureCPIGuard

덕분에 개발자는 함수 본문에서 단 한 줄의 default_verify_update 호출만으로 모든 계정 검증을 일괄 처리할 수 있다.

3.4 Anchor와의 통합 구조 및 적용 방법

SecureCPIGuard는 Anchor 프레임워크와의 호환성을 고려하여, 최소한의 코드 변경만으로 통합 가능하도록 설계되었다. 개발자는 기존의 #[derive(Accounts)] 선언 구조를 그대로 유지하면서도, 함수 본문에서 verify(...) 호출 한 줄만 추가함으로써 실행 시점의 계정 검증을 즉시 적용할 수 있다.

실제 적용 예시로, 본 논문에서 실험에 사용된 secure_update_with_guard 함수는 다음[Fig. 3]과 같이 구성된다.

Fig. 3. Example of SecureCPIGuard Integration in an Anchor Function

위와 같이 함수 시작 지점에 secure_cpi_guard::default_verify_update(&ctx)?;를 삽입하면, 해당 context에 포함된 모든 계정에 대해 signer, owner, writable 조건이 사전에 정의된 정책(Policy Struct)과 일치하는지 확인된다. 단 하나의 조건이라도 충족하지 않을 경우, 함수는 실행되지 않고 사용자 정의 오류를 반환한다.이러한 구조는 선언 기반 Anchor 모델의 보안 한계를 보완하면서도, 실행 시점의 일관된 계정 검증을 실현한다.

따라서 다음 장에서는 SecureCPIGuard 적용 전후의 보안 효과 및 성능을 실험적으로 분석하고자 한다.

IV. 실험결과 및 성능분석

4.1 실험 환경 설정 및 조건

본 실험은 제안된 SecureCPIGuard 모듈의 효과를 평가하기 위해 Solana 로컬 테스트넷 환경에서 Anchor 기반 스마트컨트랙트 프로그램을 구성하고, 다양한 조건에서 보안 검증 및 성능 측정을 수행하였다. 보안 취약점 재현과 반복 측정을 위해 블록 생성 주기와 계정 상태를 완전히 통제할 수 있는 로컬 테스트넷을 사용하였으며, 이를 통해 실험 간 재현성을 높였다. 다만, 로컬 환경은 실제 메인넷의 네트워크 지연과 분산 처리 구조를 완전히 반영하지 못하므로, 성능 수치는 실제 배포 환경과 차이가 있을 수 있다. 실험은 크게 정상 트랜잭션 호출 시의 동작 확인, CPI 기반 공격 시도의 차단 여부, 반복 호출에 따른 성능 변화 측정, 다수 공격 프로그램에 대한 차단 일관성 실험 등으로 구성되며, 각 실험별로 동일한 환경에서 조건을 통일하였다.

실험에 사용된 하드웨어 및 프레임워크 구성은 [Table 2]에 정리되어 있다.

Table 2. Experimental software and hardware environment

각 실험은 트랜잭션의 처리 시간, 성공/실패 여부, 오류 메시지, 로그 추적 결과 등을 기준으로 수치화되었으며, 동일한 조건에서 SecureCPIGuard를 적용한 경우와 그렇지 않은 경우를 비교하였다. 실험은 동일한 스마트컨트랙트 구조를 기준으로 조건만 변경하며 반복 수행되었고, 공격 시나리오의 설계는 signer, owner, writable 속성 각각에 대한 위조 계정 삽입을 중심으로 구성되었다.

4.2 SecureCPIGuard 적용 전/후 보안 비교

Anchor 기반 스마트컨트랙트는 선언적 문법을 통해 계정의 보안 속성(signer, owner, writable)을 지정하지만, 해당 조건이 실행 시점까지 강제되지 않는 구조적 한계를 지닌다. 특히 CPI 구조에서는 외부 호출자가 context 구조체의 필드를 임의로 조작할 수 있기 때문에, 선언 기반의 보안 검증만으로는 실행 단계에서의 속성 위조를 완전히 차단하기 어렵다.

이러한 구조적 취약점을 검증하기 위해, 본 연구에서는 SecureCPIGuard가 적용되지 않은 상태에서 속성 조작을 통한 공격을 설계하고, 이후 동일한 조건에서 SecureCPIGuard가 포함된 함수에 대해 재실행하여 검증 결과를 비교하였다. 공격은 signer, owner, writable 속성에 대한 위조 시나리오를 기준으로 구성되었다. 실제로 서명을 하지 않은 계정을 authority 필드에 삽입하여 signer 검증을 우회하는 공격을 수행하였다. 다음으로, 상태 저장 계정(data_account)의 소유자(owner)를 임의로 설정하여 공격자가 생성한 계정이 마치 프로그램의 상태 계정인 것처럼 위장하는 시나리오를 구성하였다.

마지막으로, 읽기 전용(readonly) 계정에 대해 is_writable 플래그를 설정하여 쓰기 가능한 계정인 것처럼 CPI context를 조작하였다. 이 세 가지 실험은 모두 실행 시점에서의 보안 검증이 존재하지 않는 경우 프로그램이 임의의 계정 변경을 허용하게 되는 취약 구조를 입증하고자 한다.

SecureCPIGuard가 적용되지 않은 함수에서는 위와 같은 공격 시도가 모두 실행되었으며, 상태값 변경이 실제로 발생하였다. 반면 SecureCPIGuard가 포함된 함수에서는 실행 시점에 각 계정 속성이 정책 조건과 일치하는지를 검증하여, 불일치 시 사용자 정의 오류 메시지를 반환하고 실행을 중단하였다. [Table 3]는 공격 조건별 SecureCPIGuard 적용 전후의 실행 결과를 요약한 것이다. 이러한 결과는 Anchor 선언 기반 보안 모델의 한계를 실험적으로 입증하며, SecureCPIGuard가 실행 시점에서 정책 기반으로 계정 속성을 검증함으로써 실질적인 방어 효과를 제공함을 보여준다. signer 및 owner 속성 위조에 대해서는 Anchor만으로는 방어가 불가능했으나, SecureCPIGuard를 적용한 경우 모든 공격 시도가 실행 전에 차단되었다. writable 속성은 일부 선언적 제약으로 차단 가능하였지만, 이는 내부 처리에 의존하므로 구조적 보완이 필요한 영역임을 확인하였다.

Table 3. Comparison of Attack Results With and Without SecureCPIGuard

4.3 성능분석

SecureCPIGuard는 실행 시점에서 계정의 signer, owner, writable 속성을 직접 검증함으로써 CPI 기반 공격을 방지하는 구조를 갖는다.

블록 생성 시점에 따른 트랜잭션 처리 성능을 측정하기 위해 블록 수에 따라 시점을 나누어 실험을 진행하였다. Solana 블록체인은 지속적으로 블록이 생성되는 구조이므로, 블록 생성 초반부(0~1000번대), 중반부(5000번대), 후반부(10000번 이상)로 나누어 동일한 트랜잭션을 실행하고 처리 시간을 측정하였다. SecureCPIGuard가 적용된 함수의 경우, 시점에 따라 평균 10~13ms 수준의 처리 시간 증가가 나타났으며, 전체적으로는 안정적인 실행 성능을 유지하였다. 실험 결과는 [Fig.4]에 나타나 있다.

Fig. 4. Execution Time by Block Range With and Without SecureCPIGuard

SecureCPIGuard 적용 유무를 기준으로 동일한 트랜잭션을 50회 반복 실행한 후, 평균 처리 시간 및 분산을 비교하였다. [Fig.5]는 각 트랜잭션 실행 시간의 변화 곡선을 곡선 근사 형태로 시각화한 결과이다. 실험 결과, SecureCPIGuard 적용 시 전체적으로 처리 시간이 소폭 증가하였으나, 평균 오버헤드는 ±5ms 내외에 불과하였다. 특히 처리 시간의 분산이 감소하고 일정한 범위 내에서 안정적으로 유지되었다는 점에서, [Fig.5]와 같이 실행 일관성 측면에서도 Guard의 적용이 긍정적인 영향을 미치는 것으로 분석된다.

Fig. 5. Transaction latency curve (fitted) comparison with/without SecureCPIGuard

공격자 프로그램 수를 증가시킨 조건에서 SecureCPIGuard의 방어 일관성을 측정하였다. 서로 다른 프로그램 ID를 가진 공격자 프로그램을 총 50개 생성하여 각각 독립적으로 배포한 후, 동일한 방식으로 위조된 계정 정보를 포함한 CPI 호출을 수행하였다.

모든 호출은 SecureCPIGuard가 적용된 함수에 대해 이루어졌으며, 그 결과 모든 공격이 사전에 차단되었다. 평균 처리 시간은 약 30~40ms 증가하였지만, 보안 검증이 모든 호출에 대해 일관되게 작동하였고, 시스템은 안정적인 처리 흐름을 유지하였다. 결과 그래프는 [Fig.6]와 같다.

Fig. 6. SecureCPIGuard successfully blocks 50 attacker programs with unique Program IDs

[Table.4]와 같이, SecureCPIGuard는 평균적으로 10~40ms 수준의 처리 시간 증가를 유발하였지만, 그에 따른 성능 저하는 실용적 관점에서 충분히 수용 가능한 범위로 판단된다. 특히 계정 속성 검증을 통해 실행 시점의 보안성이 획기적으로 강화되며, 다수의 공격자가 동시에 접근하는 상황에서도 높은 차단 일관성을 유지한다는 점에서, SecureCPIGuard는 실질적인 적용 가능성을 갖춘 경량 보안 구조임을 실험적으로 입증하였다.

Table 4. Performance Impact and Security Effect of SecureCPIGuard

V. 결론

본 논문은 Solana 스마트컨트랙트의 CPI 구조에서 발생 가능한 구조적 보안 취약점을 실험적으로 분석하고, 이를 보완하기 위해 실행 시점 보안 모듈인 SecureCPIGuard를 제안하였다. Solana의 Anchor 프레임워크는 선언 기반 검증을 제공하지만, 외부 프로그램 호출 시 context 조작을 방어하지 못하는 한계가 있다. 이러한 구조적 취약점은 signer, owner, writable 속성이 실행 시점에 검증되지 않을 경우 악용될 수 있으며, 실제 실험을 통해 Anchor만으로는 방어가 불가능한 공격 시나리오가 재현됨을 확인하였다.

SecureCPIGuard는 Anchor 구조와 호환되면서도, 프로그램 실행 시 계정 속성을 정책 기반으로 검증하는 경량 보안 계층이다. 이를 통해 외부에서 조작된 context를 탐지하고 함수 실행을 사전에 차단할 수 있으며, signer 및 owner 위조와 같은 공격에 대해 실질적인 방어 효과를 발휘함을 실험으로 입증하였다. 성능 측면에서도 평균 10~40ms 수준의 처리 시간 오버헤드만을 유발하여 안정성과 실행 일관성을 유지하였다.

본 연구는 SecureCPIGuard가 선언 기반 보안 모델의 구조적 한계를 보완하고, 실용적인 성능 범위 내에서 실행 시점 보안을 강화할 수 있음을 실험적으로 입증하였다. 이를 통해 Solana 기반 스마트컨트랙트 보안을 한층 향상시킬 수 있는 현실적인 방법론과, 실제 개발 환경에서 적용 가능한 실행 시점 검증 모델의 가능성을 제시하였다.

다만, 본 연구는 보안 취약점 재현과 반복 실험의 재현성을 위해 로컬 테스트넷 환경에서만 수행되었으므로, 메인넷 환경의 네트워크 지연·다중 검증자 병렬 처리·블록 전파 지연 등은 완벽히 반영되지 않았다. 또한 실험 범위가 signer, owner, writable 속성에 한정되어 있어, 다른 유형의 취약점이나 복합 공격 시나리오에 대한 추가 검증이 필요하다.

향후 연구에서는 퍼블릭 테스트넷과 메인넷 환경에서 성능·안정성을 재검증하고, 정책 기반 검증 로직의 자동 생성 및 경량화 알고리즘을 개발하여 실용성을 높일 계획이다. 더 나아가 복합 계정 변조, 재진입 공격, 병렬 처리 환경에서의 레이스 컨디션 등 다양한 보안 위협에 대한 대응 방안도 모색할 예정이다.

Solana를 연구 대상으로 선택한 이유는, 고성능 병렬 실행 구조(Sealevel)와 짧은 블록 생성 주기를 갖춘 플랫폼임에도 CPI 구조에서 계정 검증 미흡이라는 구조적 취약점이 확인되었기 때문이다. 특히 Anchor 프레임워크의 선언 기반 보안 모델은 개발 생산성 측면에서 장점이 있지만, 실행 시점 검증 부재로 인해 외부 프로그램 호출 시 취약해질 수 있다는 점이 본 연구의 핵심 문제의식이었다. 실험 결과, 동일한 스마트컨트랙트 구조에서 SecureCPIGuard를 적용한 경우 모든 공격이 실행 전에 차단되었으며, 평균 10~40ms의 오버헤드만 발생하였다. 이는 SecureCPIGuard가 Solana CPI 기반 스마트컨트랙트 보안을 강화하는 실용적이고 경량화된 방안임을 뒷받침한다.