[논문 리뷰] Decentralized and Stateful Serverless Computing on the Internet Computer Blockchain

Dongjun Na

Published in

취미로 논문 읽는 그룹

15 min readOct 30, 2023

이 글에서는 2023년 USENIX Annual Technical Conference에서 발표된 Decentralized and Stateful Serverless Computing on the Internet Computer Blockchain를 정리하였습니다.
Internet Computer란 DFINITY 재단에서 개발한 블록체인 네트워크 입니다. 본 글은 기술적인 내용에 집중하지만 해당 네트워크의 생태계와 블록체인 관점에서의 특징은 유튜브 (https://www.youtube.com/watch?v=rMuCZuPllEE) 및 기술 블로그에서 확인 가능합니다.

Author

나동준 (https://www.linkedin.com/in/nadongjun/)

1. 개요

본 연구는 “블록체인” 기술을 기반으로 한 “서버리스” 컴퓨팅에 대한 논문이며 기존 서버 리스의 개념에서와 반대되는 statefulness와 decentralized를 보장하는 구조를 제안합니다.

이 내용을 이해하기 위해서는 서버리스 컴퓨팅과 블록체인의 목적에 대한 간략한 기초 지식이 필요합니다.

서버리스 컴퓨팅이란,

서버 리스 컴퓨팅(Serverless Computing)은 그림과 같이 클라우드 컴퓨팅의 한 형태로, 개발자가 서버를 직접 관리하거나 프로비저닝하지 않고도 애플리케이션을 실행할 수 있는 방식을 말합니다.
이 모델에서 개발자는 자신의 애플리케이션 코드를 클라우드 서비스 제공업체의 서버리스 플랫폼에 업로드하고 실행환경을 설정하면, 플랫폼이 자동으로 필요한 리소스를 할당하고 애플리케이션을 실행합니다.

블록체인이란

블록체인 기술은 분산 환경에서 탈중앙활를 기반으로 하여 신뢰성을 보장하는 기술입니다. 최근 기술적으로는 가장 각광받는 이더리움의 지속적인 업그레이드로 웹 3.0 서비스가 발전되고 있습니다.
이더리움은 블록체인을 기반으로 스마트 계약과 탈중앙화 애플리케이션을 실행하는 플랫폼으로, 전 세계의 개발자들이 개방적이고 분산된 환경에서 애플리케이션을 개발하고 실행할 수 있도록 지원합니다.
이를 통해 블록체인 기술을 활용하여 다양한 계약 및 애플리케이션을 구축하고, 중앙 관리자 없이 데이터와 로직을 보관하는 분산 애플리케이션을 구현할 수 있습니다.

위 2가지에 대한 간단한 이해를 하셨다면 아래 요약에 대한 대략적인 이해가 가능하실 것이라고 생각합니다.

블록체인의 서버리스 컴퓨팅 개념이 추가됨 -> 이로인해 탈중앙화된 생태계는 확장됨 -> 하지만 대규모 분산 환경에서의 성능은 발전되지 않고 있음

이에 따라 본 연구에서는 Internet Computer (이하 IC)이라는 분산 플랫폼에 대한 연구를 소개하고 Web 3의 플랫폼인 분산 시스템에서의 실질적인 고려사항, 뿐만 아니라 실제 운영 데이터 기반의 실험을 통해 대규모 플랫폼에 대한 더 나은 이해를 제공하고자 합니다.

2. 시스템 구조

앞서 설명드린것과 같이 IC는 Trustless한 분산 환경에서 P2P 노드들의 컴퓨팅 자원을 활용한 (범용 프로그래밍 언어를 지원하는) 서버리스 개념을 도입하였습니다. 이를 위해서 다음과 같은 시스템 구조로 구성되었습니다.

구조는 크게 분산 환경에서 메세지 송수신을 위한 P2P 레이어, 분산 환경에서 메세지에 대한 Ordering 및 검증을 위한 합의 레이어, 추후 설명될 메세지 라우팅 및 소스코드 실행을 위한 실행 레이어로 구성되며 각 구조는 다음과 같습니다.

각 구조에 대한 설명 전 용어에 대해 먼저 정리하겠습니다.

IC: Internet computer network
Subnet: IC에서의 분할 단위
Node: 네트워크를 구성하는 노드, State 유지 및 소스코드 실행 역할
Canisters: 서버리스로 실행할 소스코드

-> 요약: IC를 기반으로 모든 노드가 통신을 하며 각 노드는 Subnet 단위로 분할되어 있으며 각 Subnet에는 Canister라고 하는 소스코드가 저장되어 있다.

Internet Computer 특징

IC에서는 위와 같은 소스코드를 IC 네트워크에 배포하고 사용자는 네트워크를 구축하고 있는 노드들의 컴퓨팅 자원을 활용하여 소스코드를 실행하고 이에 대한 State를 분산 네트워크에 저장하게 됩니다. 하지만 중앙 시스템과 달리 분산 시스템에서는 매우 많은 고려사항이 존재합니다.

3–1 기술적 한계점

위 구조에서는 p2p, 합의 알고리즘, 메세지 라우팅, 실행 환경으로 나뉘며 각각에 대한 기술적 한계점이 존재합니다.

decentralized and stateful serverless 컴퓨팅을 제공하기 위해서는 여러 한계가 존재하지만 본 논문에서는 Execution Environment에 집중합니다.
중앙 시스템과 달리 실행에 대한 증명을 위해서는 각 State에 대한 기록이 필요하며 합의를 위해서는 결정론적인 소스코드의 실행이 보장되어야 합니다. 이를 위해서 2가지 챌린지를 해결합니다.

Challenge 1: Statefullnes를 어떻게 보장?, 기존 Serverless 컴퓨팅과 달리 소스코드로 실행한 연산에 대해서 Statefullness가 보장되어야 함

Challenge 2: Deterministic를 어떻게 보장?, 탈중앙화된 환경에서 여러 노드가 소스코드를 실행시켜야 하므로 소스코드 실행에 대한 Deterministic이 요구됨

3–2 해결책

위 2가지를 해결하기 위한 본 연구의 Contribution 입니다.

C1 — Statefulness — The Memory Subsystem
C2— Deterministic Scheduling

Contribution 1: The Memory Subsystem

The execution of messages instantiates a Wasmtime instance in a sandboxed environment. [7]

소스코드 실행에 대한 결과값인 State의 변화가 영구적으로 저장되고 추적되어야 하며 이를 위해서 본 연구에서는 다음과 같은 구조를 사용하였습니다.
Internet Computer의 아키텍처는 다음과 같은 구성 요소로 나누어집니다: Wasm Binary, Memory Pages, Heap Delta, 그리고 Checkpoint File로 이루어지며 Canister의 상태 및 메모리 관리 역할을 합니다.

Wasm Binary:

Wasm Binary는 WebAssembly (Wasm) 형식의 실행 가능한 코드로, Canister의 기능을 정의하는 프로그램입니다. 이 바이너리는 Canister가 실행할 수 있는 로직, 함수, 그리고 스마트 계약의 코드를 포함합니다.
또한 Canister의 초기 상태를 정의하며, 이진 형식으로 저장되고 관리됩니다. Canister가 시작될 때 메모리에 로드되어 실행됩니다.

2. Memory Pages:

Memory Pages는 Canister 메모리의 단위입니다. 블록체인 네트워크의 노드에서 분산되어 복제되며 Canister의 상태, 데이터, 그리고 실행 환경을 저장합니다.
Canister의 상태와 데이터는 Memory Pages에 저장되고, 이 페이지들은 Canister의 실행 중에 읽고 업데이트됩니다. 상태 변경 및 계산의 결과는 이러한 메모리 페이지에 기록됩니다.

3. Heap Delta:

Heap Delta는 Canister의 메모리 상태 변경을 추적하는 방법입니다. Canister가 실행 중에 상태를 업데이트하면 Heap Delta가 변경 내용을 기록하고 관리합니다.
Heap Delta는 상태 변경 사항을 추적하기 위한 효율적인 방법으로 사용되며, 변경된 메모리 페이지를 저장하고 이를 블록체인에 반영하는 데 사용됩니다.

4. Checkpoint File:

Checkpoint File은 Canister의 메모리 상태를 영구적으로 저장하고 관리하기 위한 파일입니다. 이 파일은 Canister의 현재 상태를 체크포인트로 저장하여, Canister가 중지될 때나 상태가 복구되어야 할 때 사용됩니다.
Checkpoint File은 Canister의 상태를 지속적으로 유지하고 블록체인 네트워크에서 분산하여 Canister의 영속성을 보장합니다.

동작 과정

Internet Computer에서 상태 변경은 메모리에 기록된 델타(변경 사항)를 사용하여 처리되며, 변경된 상태는 영구적으로 저장됩니다. Checkpoint 파일은 Canister의 상태 변경을 저장하는 중요한 역할을 하며 동작 방식은 다음과 같습니다:

Write Access 및 Delta 생성: Canister가 상태를 변경할 때 “delta”가 생성됩니다. delta에는 상태 변경 사항이 포함되어 있습니다.
Delta 저장 및 Checkpoint File 업데이트: Delta는 Checkpoint 파일에 저장됩니다. Checkpoint 파일은 Canister의 영속적인 상태를 저장하는 중요한 장소입니다. Delta는 Checkpoint 파일에 추가되고 Canister의 현재 상태가 업데이트됩니다.
Read Access 및 메모리 페이지 업데이트: Read Access가 발생하면 필요한 페이지를 Memory Pages로 가져옵니다.
Memory Pages를 통한 읽기 또는 쓰기 작업: 메모리 페이지에 읽기 또는 쓰기 작업이 수행됩니다. 메모리 페이지의 내용은 Checkpoint 파일 및 현재 상태에 따라 업데이트됩니다.

결과적으로, Checkpoint 파일은 Canister의 영속적인 상태를 저장하며, Memory Pages는 실행 중에 메모리에 로드되어 실시간으로 메모리 상태를 나타냅니다. Delta는 상태 변경 사항을 추적하고 Checkpoint 파일에 저장됩니다. Delta는 일반적으로 Checkpoint 파일과 메모리 페이지 간의 데이터 일관성을 보장하는 데 사용됩니다.

Contribution 2: Wasm execution, Deterministic Scheduling

IC는 분산된 노드들이 메세지에 따라 같은 소스코드를 실행합니다.

일관성 문제: 여러 노드가 서로 다른 시간 슬라이스에서 코드를 실행하거나 상태를 변경할 경우, 서로 다른 결과를 생성할 수 있습니다. 이는 분산 시스템에서 데이터 일관성을 유지하는 데 중요한 문제입니다.
예를 들어, 하나의 노드가 데이터를 업데이트하는 동안 다른 노드가 동일한 데이터를 다른 방식으로 업데이트할 경우 데이터 일관성이 깨질 수 있습니다.

Wasm 실행 최적화

아래 내용은 웹어셈블리(Wasm) 코드에 대한 계산량을 측정하고 메시지 실행을 감시하는 메커니즘인 “Time-slicing and Accounting”에 대한 4가지 설명입니다. 블록체인 환경에서 스마트 계약의 악의적인 또는 오류가 있는 메시지 실행이 무한히 오래 실행될 가능성을 방지하기 위한 방법을 다룹니다.

Termination of Message Execution: Wasm 코드가 튜링 완전(어떠한 컴퓨팅 시스템이 알고리즘을 수행할 수 있는 충분한 계산 능력을 갖추었음)하기 때문에 메시지 실행의 종료를 보장해야 합니다. 그렇지 않으면 악의적인 스마트 계약이 블록체인의 진행을 막을 수 있습니다. 종료 지점은 결정론적이어야 하지만, 실행 시간은 노드 간의 무결정적 이벤트로 인해 약간 다를 수 있습니다.
Instruction Counting: 해결책으로 Wasm 코드를 계산된 명령어의 수를 측정하기 위해 “인스트럭션 카운팅”을 사용합니다. 이는 각 메시지의 실행 동안 실행된 명령어 수를 계산하기 위한 것입니다.
Resource Accounting: 인스트럭션 카운팅을 통해 계산한 작업량을 사용하여 계산을 정확하게 청구할 수 있습니다. 스마트 계약은 계산, 통신 및 저장소와 같은 소비하는 리소스에 대해 청구됩니다. 이로 인해 인터넷 컴퓨팅(IC)는 시스템 내의 모든 캐니스터의 리소스 사용량을 기록해야 합니다. 예를 들어, 메모리 액세스(읽기 및 쓰기한 페이지 수를 기준으로 추정) 및 CPU 명령어 사용량 등의 리소스가 청구됩니다.

요약하면, “Time-slicing and Accounting”은 Wasm 코드의 실행을 추적하고 리소스 사용량을 계산하여 메시지 실행을 효율적으로 관리하기 위한 메커니즘입니다. 블록체인 환경에서 불특정 기간 동안 실행되는 악의적인 메시지로부터 시스템을 보호하고 효율적인 자원 관리를 가능하게 합니다.

Deterministic Scheduling

위에서 언급된 것과 같이 실행 환경에서 소스코드를 샌드박스화 하여 컴퓨팅 자원의 분배가 가능합니다. 하지만 실행에 대한 Deterministic이 보장되지 않는다는 문제점이 여전히 존재합니다.

Consensus Protocol: Canister에서 동일한 입력을 동일한 순서로 처리하도록 보장하기 위해 서브넷 내의 노드는 합의 프로토콜을 실행합니다. 이 합의 프로토콜은 입력을 동일한 순서로 처리하도록 보장합니다. 이때 IC 코드 및 캐니스터 코드가 결정론적이라면 각 복제본의 내부 상태는 시간이 지남에 따라 정확히 동일한 방식으로 업데이트되며, 하드웨어 관련 문제가 없는 한 각 노드는 정확히 동일한 출력 시퀀스를 생성합니다.
Scheduler Granularity: 스케줄러는 캐니스터 대신 개별 메시지를 스케줄링하고, 각 캐니스터를 해당 큐의 메시지가 더 이상 없거나 라운드당 시스템에서 정의한 명령어 제한에 도달할 때까지 실행하는 덜 세분화된 레벨에서 작동합니다.

이 스케줄링 알고리즘은 State machine(Canister)에서 메세지를 정확하게 처리하고 자원을 효율적으로 할당하는 데 사용되며, 공정성과 결정론적 동작을 보장합니다.
추가적으로 메세지가 실행될 때 스케줄러에서 고려되지 않은 “실행 시간”으로 인해 발생되는 한계점 또한 해결하였습니다.

스케줄링의 문제: 메시지는 라운드 단위로 실행되는데, 일부 메시지는 라운드 내에서 실행이 완료되고 일부는 정의된 명령어 수 제한에 도달할 때 실행이 중단되고 오류가 발생한다고 설명합니다. 이 경우 긴 실행 시간을 갖는 메시지는 여러 실행 라운드에 걸쳐 실행이 되어야 하며 이러한 방식은 라운드 간격 증가가 발생하여 전체 처리량과 속도 저하, CPU 낭비로 이어질 수 있다는 문제가 있습니다.
이러한 문제를 해결하기 위해 “결정론적 시간 분할 메커니즘”을 도입하였습니다. 이 메커니즘은 메시지의 실행 시간이 라운드를 초과하는 경우, 실행을 동일한 명령어 수의 간격으로 분할하는 것을 의미하며 메세지로 실행되는 명령어 수와 시간 간격으로 동일하게 분배하여 각 라운드마다 실행을 효율적이고 결정론적으로 수행할 수 있습니다.
따라서 긴 실행 시간을 갖는 메시지를 효율적으로 처리할 수 있습니다.

결론

본 연구에서는 Decentralized statefulness serverless를 가능하게 하기 위한 Low-level의 시스템 챌린지들을 해결 방법을 제안하였습니다.
제안된 구조는 분산 환경에서 소스코드 실행 결과에 대한 State를 영구적으로 저장 및 추적할 수 있으며 Time Slicing을 통해 결정론적인 실행으로 일관성을 보장하여 Trustless한 환경에서 소스코드 실행에 대한 신뢰성을 보장할 수 있습니다.
이 연구에서는 Web 3 구조에 대한 필요성과 같은 Motivation 부분은 아직 잘 이해를 못하였지만 기존 솔리디티에 집중되었던 web 3 개발 환경을 확장시켜 탈중앙화된 환경에서 컴퓨팅 환경을 제공하기 위한 최적의 구조를 제안했다는 점에서 의미가 있다고 생각하며 클라우드, 엣지 컴퓨팅에 이은 새로운 컴퓨팅 시스템 구조로 발전되길 바랍니다.