ALUX Network

전역 VM구축

퍼블릭 블록체인, 프라이빗 클러스터, 휴대전화와 브라우저 같은 클라이언트 환경까지 어디서나 실행되는 하나의 논리 가상 머신을 상상해 보십시오. 상태, 스레드, 복제, 합의 같은 기반의 차이는 하나의 추상화 아래 감춰집니다. 개발자는 동시성 프로그램 하나만 작성하면 됩니다. 실행 위치는 아키텍처의 제약이 아니라 설정으로 선택합니다. 각 부분은 하나의 원자적 결과로 함께 커밋됩니다. 이것이 가상 머신 추상화이며, ALUX가 구축하고 있는 것입니다.

하나의 논리 실행 계층 물리적으로 분산

GLVM은 여러 TVM을 아우르는 하나의 동시성 실행 모델을 개발자에게 제공합니다. 현재 기반은 ALUX 체인 런타임입니다. 프라이빗 클라우드는 다음 통합 대상이며, 클라이언트 기기 배포는 로드맵 단계입니다.

월드 운영 체제

서비스 / 에이전트 등록 및 탐색 / 서비스 / 에이전트 오케스트레이션 / 프로그래밍 가능한 권한

ALUX — 탈중앙화 동시성 런타임

GLVM / 상태 + 스레드 / 복제 / 합의

물리 인프라

공용 블록체인 / 프라이빗 클러스터 / 클라이언트 하드웨어

월드 운영 체제

서비스 / 에이전트
등록 및 탐색
서비스 / 에이전트 오케스트레이션
프로그래밍 가능한 권한

ALUX — 탈중앙화 동시성 런타임

GLVM
상태 + 스레드
TVM
복제
TVM
합의
TVM

각 머신은 하나의 TVM을 실행하며, 이들이 함께 GLVM을 구성합니다.

물리 인프라

공용 블록체인

블록체인 노드

TVM
TVM
TVM
프라이빗 클러스터

클라우드 / 엔터프라이즈 노드

TVM
TVM
TVM
클라이언트 하드웨어

휴대전화 / 브라우저

TVM
TVM
TVM

ALUX 기능 지도

모듈을 ALUX Runtime으로 드래그하여 하나의 GLVM 모델 안에서 어떻게 조합되는지 확인해 보십시오.
카드를 더블클릭하면 자세한 설명을 볼 수 있습니다.

한 번 탭하면 모듈의 자세한 설명이 열립니다.
두 번 탭하면 ALUX Runtime에 연결되고 조합된 VM 안에서의 역할을 확인할 수 있습니다.

ALUX Runtime으로 드래그더블 클릭으로 의미 확인한 번 탭 · 자세히 보기더블 탭 · 런타임에 연결
런타임 연결모듈을 ALUX에 연결

모듈을 ALUX Runtime에 놓아 GLVM 안에서 어떻게 조합되는지 확인해 보십시오.

카드를 더블 클릭하면 뒷면에서 이 모듈의 역할, 중요성, 실제 영향을 간결하게 확인할 수 있습니다.

활용 사례

ALUX에서 무엇을만들 수 있는가

대기하는 동안에도 컨텍스트를 유지하고, 병렬 작업을 조정하며, 하나의 결과로 확정되는 워크플로를 구축할 수 있습니다. 현재 지원 기능과 로드맵 목표는 구분해 표시합니다.

01

온체인 장기 실행 AI 에이전트

워크플로는 여러 에이전트를 병렬로 시작합니다. 일부는 Claude API를 호출하고, 다른 단계는 사용자 입력을 기다립니다. 워크플로가 약 30분 동안 실행되더라도 메인 에이전트는 모든 분기가 완료된 뒤에만 실행을 이어 갑니다. Claude API와 사용자 입력의 연결은 애플리케이션 계층에서 담당하며, ALUX는 내구성 있는 fork, wait, join, capability 전달과 재현 가능한 실행을 제공합니다.

durable-agent.tox런타임 + 애플리케이션 통합
에이전트 forkClaude 호출사용자 입력 대기모두 join계속 실행
02

세 거래소의 BTC 가격 집계

계약은 구성된 외부 I/O 어댑터를 통해 세 개의 프로세스를 병렬로 시작해 Binance, Coinbase, Kraken의 BTC 가격을 읽습니다. 네 번째 프로세스는 세 프로세스가 모두 끝날 때까지 기다린 뒤 결과를 join하고, 시세를 정규화하고, 중앙값을 계산한 다음 실행을 이어 갑니다. ALUX는 실행을 재현 가능하게 만들지만, 어떤 값을 원본으로 신뢰할지는 선택한 엔드포인트가 결정합니다.

btc-median.tox지원되는 I/O 경로
BINANCE
COINBASE
KRAKEN
JOIN → 중앙값
03

크로스 샤드 원자적 실행

Shard A의 contract a는 Shard B의 contract b가 관리하는 티켓의 결제를 스테이징합니다. 티켓이 이미 판매되어 b가 실패하면 a의 결제는 롤백됩니다. 두 단계가 모두 성공할 때만 결제와 티켓 소유권이 함께 커밋되며, 다른 트랜잭션에는 부분 상태가 전혀 보이지 않습니다. 크로스 샤드 원자적 실행은 로드맵 목표이며 현재 운영 중인 기능이 아닙니다.

티켓 정산로드맵
결제 / A원자적 링크티켓 / B
둘 다 커밋하거나 둘 다 중단
04

규칙을 조합할 수 있는 프로그래머블 머니

Alice는 1 ALUX가 담긴 권한형 지갑(purse)을 Bob에게 전달하면서 ‘자금은 10일 이내에 사용해야 한다’는 규칙을 추가합니다. Bob은 같은 지갑을 Carole에게 전달할 때 ‘도서 구매에만 사용할 수 있다’는 두 번째 규칙을 추가합니다. Carole은 두 규칙을 모두 충족해야 하며, 지갑을 전달해도 자금은 복제되지 않습니다. 기한과 사용처 규칙은 애플리케이션 로직으로 집행됩니다.

1 ALUX가 담긴 지갑애플리케이션 정책
Alice10일 이내 사용
Bob도서 구매만
Carole두 규칙 모두 적용
일회성 트랜잭션을 넘어 구축하기

장기 실행 워크플로를 뒷받침하는 런타임 프리미티브를 살펴보십시오.

Runtime Lab에서 ALUX 실행 모델의 fork, wait, join, 외부 입력, 재생, 원자적 확정을 살펴보십시오.

Runtime Lab 열기

자주 묻는 질문

자주 묻는 질문

질문을 클릭해 답변 보기

ALUX에서는 일반 스마트 컨트랙트가 못 하던 무엇이 가능해지나요?
ALUX는 스마트 계약 모델을 장기 실행 작업을 위한 탈중앙화 내구 실행 엔진으로 확장합니다. 워크플로는 동시성 프로세스를 실행하고, 블록을 넘어 중단하며, 외부 도구나 사람을 기다렸다가 재개하고 결과를 join하면서도 절반만 완료된 상태를 노출하지 않습니다. 런타임이 중개하는 외부 채널은 별도의 오라클·릴레이어 조합 없이 지원되는 오프체인 서비스와 상호작용할 수 있습니다. 아키텍처는 같은 원자적 모델을 수평으로 확장해 크로스 샤드 효과가 함께 커밋되거나 중단되도록 설계되어 있으며, 크로스 샤드 실행은 로드맵에 남아 있습니다.
왜 ALUX는 AI 에이전트에 적합한가요?
온체인 에이전트는 본질적으로 장기 트랜잭션입니다. LLM이나 도구를 호출하는 데는 시간이 걸리고, 사람의 응답을 기다리는 데도 시간이 필요합니다. 이 워크플로를 즉시 끝나는 단일 블록 호출에 억지로 맞출 수는 없습니다. ALUX에서는 실행 컨텍스트를 보존하고, 중단한 뒤 입력이 도착하면 재개하며, 여러 에이전트를 동시에 조정하고, 재현 가능한 실행으로 확정할 수 있습니다.
ALUX는 또 하나의 더 빠른 L1인가요?
아닙니다. 더 빠른 L1은 같은 추상화, 즉 한 블록 안에서 일어나는 일회성 상태 업데이트를 가속합니다. ALUX는 기다리고, 재개하고, 여러 채널을 합치거나, 가장 먼저 준비된 채널을 선택할 수 있는 장기 트랜잭션(Long Transaction)을 위한 탈중앙화 동시성 런타임입니다. 상태 업데이트는 더 이상 블록 경계에 제약되지 않습니다. GLVM 아키텍처인 가상 머신 추상화를 통해 동일한 논리 트랜잭션은 블록 경계를 넘어 샤드와 시스템 경계까지 확장되도록 설계됩니다.
다른 체인도 크로스 블록 트랜잭션을 지원한다고 주장합니다. ALUX는 무엇이 다릅니까?
핵심은 원자성입니다.

보상 / Saga: commit → commit → ✗ fail → run compensating undo
각 단계는 로컬에서 커밋되고 중간 상태가 노출되며, 보상 자체도 실패할 수 있고 외부 효과를 항상 되돌릴 수 있는 것은 아닙니다. 이것은 최종 일관성입니다. ICP와 Rialo를 포함한 일부 비동기 체인은 이 모델에 의존합니다. 구현은 더 쉽지만 더 강한 ACID 보장이 필요한 애플리케이션에는 적합하지 않습니다.

ALUX 전부 아니면 전무: stage → stage → ✗ fail → discard everything
전체 트랜잭션이 커밋될 때까지 아무것도 커밋되지 않습니다. 중단되면 커밋되지 않은 효과는 모두 폐기되고 부분 상태는 관찰되지 않습니다. 이것이 블록 높이를 아우르는 진정한 ACID 원자성입니다.
ALUX는 장기 트랜잭션의 결정성을 어떻게 유지하나요?
ReplayTrie는 실행 결과에 영향을 주는 비결정적 COMM 선택을 기록합니다. 따라서 검증자는 ALUX 런타임 경계 안에서 동일한 실행 결과를 비트 단위로 정확하게 결정론적으로 재실행할 수 있습니다.
객체 권한(Object Capability, OCAP)이란 무엇입니까?
객체 권한(Object Capability, OCAP)은 코드가 어떤 리소스에 접근하려면 그 리소스에 대한 참조, 즉 권한(capability)을 명시적으로 전달받아야만 하는 보안 모델입니다. OCAP 시스템에서는 동일한 객체 참조가 리소스를 지정(designation)하는 동시에 그 리소스를 사용할 권한을 부여(authorization)합니다.
OCAP가 더 강력하고 조합 가능한 보안 모델인 이유는 무엇입니까?
객체 권한(OCAP)이 더 강력한 보안 모델인 이유는 권한을 전역 ID나 접근 제어 목록이 아니라 명시적이고 위조할 수 없는 capability로 표현하기 때문입니다. OCAP은 ‘지정이 곧 권한 부여다(designation is authorization)’라는 원칙을 따릅니다. capability를 보유하면 리소스를 식별하는 동시에 해당 리소스의 사용 권한을 얻으므로, 주변 권한(ambient authority)을 제거하고 공격 표면을 줄일 수 있습니다. capability는 안전하게 위임·축소·회수할 수 있어 보안 정책이 중앙 집중식 권한 시스템 전반에 흩어지지 않고 관련 객체에 국소화됩니다. 따라서 OCAP은 자연스럽게 조합 가능하며, 최소 권한 원칙을 유지하면서 독립적으로 안전한 구성 요소로 복잡한 애플리케이션, 스마트 컨트랙트, AI 에이전트 워크플로를 구축할 수 있습니다.
ALUX가 OCAP를 네이티브로 지원한다는 것은 무엇을 의미합니까?
ALUX의 튜플 공간 가상 머신(TVM)은 객체 권한(OCAP) 모델을 바이트코드 수준에서 직접 구현합니다. 명령어 집합에는 임의의 객체 참조를 위조하거나 생성하는 연산이 없으므로, 권한은 명시적 위임을 통해서만 획득할 수 있습니다. 따라서 모든 권한이 위조 불가능하고 명시적으로 이전된다는 점이 보장됩니다.
기존 스마트 컨트랙트 개발자도 사용할 수 있나요?
TVM은 격리된 샌드박스에서 EVM 바이트코드를 실행하므로 대부분의 EVM 계약을 최소한의 변경으로 ALUX에 마이그레이션할 수 있습니다. ALUX는 일반적으로 사용되는 eth_* JSON-RPC 메서드 집합을 통해 Ethereum 호환 뷰도 제공합니다.