Aion에 대해서 알아보자
Aion 백서 분석
글을 다 작성한 뒤에 2번 정도 글을 읽으면서 글에 영어 혹은 영어표현이 너무 많은 점을 발견했습니다. 백서의 내용 중 원작자의 의도를 그대로 전달하는 것이 옳다고 생각을 했기 때문에 영어표현을 직역하거나 아니면 한글과 함께 표기했습니다. 더불어 낯선 용어가 많아 이해하기 어려운 내용이 많다고 생각이 드는데, 다음에는 쉬운 언어로 누구도 이해하기 쉽고 통찰력이 있는 글을 쓰도록 노력하겠습니다.
그동안 인터체인 프로젝트 3가지 백서를 읽으면서 인터체인의 기술성과 시장성을 평가하는 데에 필요한 요소는 무엇인지 정리해보고, 그 기준에 따라 3가지 프로젝트를 비교 분석하는 글을 작성해보고자 합니다. 블록체인과 관련한 재미있는 프로젝트 혹은 아이디어에 대해서 듣는 것은 정말 즐거운 일이기 때문에 편하게 연락 주시면 감사하겠습니다. 여러분의 피드백은 더 많은 배움과 성장에 좋은 자양분이 됩니다.
Aion
- 개요
미래에 블록체인은 데이터를 연합(Federate)하고 인터넷과 유사하게 Hub and Spoke 모델로 발전해나갈 것이고 Aion은 나눠진 블록체인들을 통합할 수 있는 네트워크가 되기를 지향합니다. Aion은 3세대 블록체인으로 Private/Public 블록체인 기관들이 아래와 같은 기능을 할 수 있게 합니다. Aion내 블록체인과 이더리움 간의 데이터와 가치를 보낼 수 있으며, Aion 네트워크에 있는 블록체인들간 데이터 용량(Capacity)를 증가시키고 빠른 거래를 지원합니다. 다른 블록체인 간의 상호운용성(Interoperability)를 유지하면서 개인화된 Public/Private 블록체인을 만들 수 있도록 지원합니다. 각 Publisher들은 거버넌스, 합의 메커니즘, 발행, 참여 등을 설정할 수 있습니다.
2. 구성요소
2.1. Connecting Network
Connecting Network는 인터체인 다양한 개인 또는 공공 블록체인 네트워크 사이의 커뮤니케이션과 거래를 촉진하는 네트워크입니다. Connecting Network와 인터체인 거래는 블록체인 개발자와 사용자에게 하나의 네트워크로부터 다른 네트워크로 메세지를 보내는 전반적인 인터페이스를 제공합니다. 특히, Connecting Network는 타 블록체인 네트워크 간 메세지를 Bridge Protocol을 통해 보내고 최종적으로 된 메세지를 전파하고 분권 책임(Decentralized Accountability)을 제공합니다.
각각의 Conneting Network의 기능과 내부 구성 요소는 의도한 목적에 따라 다를 수 있지만 해당 핵심 기능은 구현해야 합니다. 인터체인 같이 Point와 Point간의 연결에는 허브로써 존재하고, Bridge와 신뢰가 불필요한(Trust-free) 블록체인 네트워크를 이용하여 Transaction 흐름의 정확성을 확인하고 보장 해야 합니다.
2.1. 인터체인 트랜잭션(Interchain Transaction)
인터체인 트랜잭션은 블록 체인 네트워크 간 신뢰할 필요가 없는(Trust-free) 메세지로 연결된 블록 체인 네트워크가 정보를 교환하게 도와줍니다. 한 블록체인은 인터체인 트랜잭션을 생성해서 Bridge와 Connecting Network을 통해 목표 Blockchain에 도달할 수 있습니다. 처음 거래를 생성한 사람은 Aion Token을 이용해서 커뮤니케이션에 대한 거래 비용을 내야 하고 이 비용은 해당 루트에 있는 모든 참여자들에게 유인책이 됩니다.
2.1.1. 형식
Payload data: 거래를 처음 만든 사람에게 해당되며 일반적으로 거래 데이터를 포함하지만 소스 네트워크(Source Network)와 창작자의 재량에 따라 상이
Metadata: 경로(Routing) 정보와 수수료를 포함하는 Interchain 거래 정보
Merkle proof: 보내는 사람이 Bridge를 건너뛸 때 사용
Bridge와 Connecting Network의 검증자는 Data를 해석하지는 않지만 거래의 진실성은 확인합니다. 프라이버시에 민감한 정보는 데이터를 암호화 할 수 있습니다. Interchain 거래의 경로는 다중 단계 과정(Multi-phase process)으로, 검증자는 거래를 검증하고 합의가 승인 될지 혹은 거절될지 결정합니다. 만약에 거래가 거절 당하면 상태 변화는 되돌려질 수 있습니다. Connecting Network는 Participating Network 머클 해시 Chain의 정보에 기반해 Interchain 거래를 검증하고 타당할 경우 전파(Broadcast)합니다. Participating Network의 정의는 뒤에서 서술했습니다.
2.1.2. 상태
Interchain 거래는 Bridge 검증자에 의해서 Participating Network에서 발견되었을 때에 Receive로 상태가 전환됩니다. Bridge 검증자들 중 2/3 이상이 Interchain 거래에 찬성을 했을 때, 연결된 네트워크는 상태를 On Hold로 변경하고 거래가 처리될 때까지 네트워크 토큰이 예치 됩니다. 일단 목표 Blockchain에서 승인이 되면 상태는 Confirmed로, 승인이 되지 않는다면 상태는 Time Out이 됩니다. 만약 2/3보다 낮은 비율로 Bridge 검증자가 Interchain 거래를 동의한다면, 상태는 Rejected로 바뀝니다. 모든 Interchain 거래가 끝나면 상태는 Finalized로 바뀌고 모든 예치된 수수료는 Connecting Network와 검증자에게 분배됩니다.
2.2. Bridge
Bridge는 Participating Network와 Connecting Network간 소통을 활성화시키는 프로토콜로, 네트워크간 책임성(Accountability)과 프로토콜간 전환(Translation)을 검증하는 고유한 검증자를 가지고 있습니다. 거래 수수료가 지불된 경우에만 거래를 승인하고, Participating Network의 머클 해시 업데이트를 Connecting Network에 알립니다. Connecting Network와 Participating Network 개념은 상대적으로 2.1. 하단의 그림을 참조하시면 좋습니다.
2.2.1. 등록과 경쟁
Bridge가 타당해지려면 최소한의 Stake가 요구되고, 오직 Top 검증자만이 합의 알고리즘에 참여할 수 있습니다. 복수의 검증자 집단이 같은 블록체인 네트워크에 등록이 되면 복수의 Bridge가 생길 수 있습니다. 어떤 Bridge를 사용할 지는 Target Network를 구체화하는 시점에 사용자가 결정합니다. 다른 Bridge들이 안정성, 명성, 가격, 마켓의 수요에 의해 측정된 최적의 수수료 측면에서 서로 경쟁하면서 Open market을 만들 것 입니다.
2.2.2. Bridge 합의 구조
Bridge 검증자는 Lightweight BFT기반 합의 알고리즘을 사용하여 2/3 이상의 승인을 받았을 때만 거래가 승인됩니다. Bridge 검증자 들은 서명과 수수료의 타당성을 검증하고 둘 다 타당했을 때 서명하고 다음 과정으로 전파합니다.
2.2.3. 수수료
Bridge 검증자들은 Interchain 거래 수수료와 Block Reward일부분을 보상 받습니다. 내부적으로 Bridge로 가는 모든 수수료는 Bridge 검증자들에게 지분에 따라 혹은 균등하게 분배됩니다. 외부적으로 Bridge는 Routing Path(처음 거래를 보낸 블록체인 부터 도착 지점까지의 과정)에 있는 다른 Bridge와 Connecting Network의 검증자와 수수료를 나눕니다.
이 과정에서 두가지 분배 모델이 존재하는데, 첫번째는 거래를 보내는 사람이 수수료의 분배를 결정하는 것입니다. 이 모델의 장점은 사용자가 수수료를 최적화 할 수 있다는 점이지만, 단점은 사용자가 Routing Path와 각 Bridge의 수수료 체계에 대해서 미리 알고 있어야 한다는 점입니다. 두번째 방법은 보내는 사람은 총 수수료만 정하고 Bridge와 Connecting Network는 합의 또는 Hard-coded 프로토콜에 기반해 수수료를 나눕니다. 해당 모델은 사용자에게 간단한 장점이 있지만, 이 모델의 단점은 Bridge와 Connecting Network사이의 비율의 변화가 느리다는 것입니다.
2.3. Participating Network
Particitpating Network는 Connecting Network와 연결되는 주체입니다. Participating Network는 블록체인 뿐만 아니라 Oracles(외부데이터), Cryptlets, Database Cluster가 될 수 있습니다. 한번 Participating Network로 Aion Network에 포함되면 인터체인 거래에 접근할 수 있으며, 각 Participating Network는 자체 합의/Hashing 알고리즘, Virtual Machine(VM)과 Scribing Language를 설정할 수 있습니다. 즉 Participating Network는 Connecting Network와 상관없이 자체 환경 설정을 할 수 있는 것입니다.
2.3.1. Aion Compliant Blockchains
Aion-compliant 블록체인은 Aion Protocol에 부합하는 Participating Blockchains을 의미합니다. Aion Compliant Blockchain위에서 Bridge는 Aion-1을 통해 인터체인 트랜잭션을 시행하기 위해서 쉽게 설립될 수 있습니다. 즉, Aion Network 상 받아 들여질 수 있는 모든 Blockchain은 Aion Compliant Blockchains로 여겨집니다. 위에서 설명한 Connecting Network와 Participating Network모두 Aion Compliant Blockchain으로 생각할 수 있습니다.
2.3.2. 현존하는 네트워크의 호환성
현존하는 블록체인 프로제트는 상호 운용 가능하게 설계되지 않았습니다. Aion Network와 상호 운용이 가능하게 하려면, 추가적인 가정이나 합의가 필요합니다.
- Aion에서 Ethereum으로
이더리움은 Aion Network와 다른 합의 구조를 가지기 때문에, 인터체인 거래 계약이 필요합니다. 인터체인 거래 계약이 요청되었을 때 Bridge 검증자들은 그들의 개인 키를 서명하고 인터체인 거래 계약에 서명을 전송합니다. 2/3 이상의 투표를 받았을 때 인터체인 거래가 승인됩니다. 다중 서명 검증의 비용이 이더리움 상에서 비싸기 때문에(단일 ECDSA에 3,000gas소요) 높은 Bridge 요금이 예상됩니다. 해당 비용을 낮추기 위해서, BFT 기능을 가진 블록체인은 투표 결과만을 이더리움 상에 저장합니다.
- Ethereum에서 Aion으로
Ethereum의 Programmable 거래 사이즈 덕분에 이더리움에서 Aion으로 인터체인 트랜잭션을 보내는 일은 어렵지 않습니다. 받는 주소에 따라 거래 방식이 다른데, 전송이 외부 소유 계정으로 되는 경우 데이터 Field는 수정없이 사용될 수 있습니다. 만약 전송이 계약 계정으로 보내진다면, 데이터가 Ethereum VM에 의해 해석되면서 추가적인 일이 필요합니다.
Q: 호환성 문제에 대해서 Aion에서 Ethereum으로 연동할 때에 서명만 보내면 호환이 되는 것처럼 서술이 되어 있습니다. 하지만 타 블록과 호환을 한다는 것이 Atomic Swap을 의미하는 지 아니면 새로운 방식을 도입하는 지 알기 어렵습니다.
2.4. AION-1 Blockchain
Aion-1 blockchain은 분산화되고 Multi-tier 블록체인 네트워크 구조에 필수적인 Open된 블록체인 구조로 디자인 되었습니다. 블록체인과 외부 서비스(Oracles and Databases)를 인접한 네트워크에 연결하고 고성능, 분산화, Inter-blockchain application을 개발하는 데 필수적인 기반(Infrastructure)을 제공하는 것을 목표로 하고 있습니다.
3.1. 용어정리
- Backers
검증자를 지지하는 노드를 의미합니다. 검증자 숫자보다 많은 Backers는 그들의 검증자의 보상에 기반을 해서 보상을 받습니다. Bakers들은 Stakers와 Solvers로 나뉩니다.
- Stakers
검증자에게 토큰을 약속한 Backers의 집단을 의미하며, 일정 금액을 네트워크 상에 예치해야 합니다.
- Solvers
Proof of Intelligence를 이용하면서 네트워크에서 주어진 암호학적인 퀴즈를 풀기 위한 사용자입니다. 해당 퀴즈를 다 푼 이후에 그 Solution을 바탕으로 검증자를 지지할 수 있습니다. PoW 방식의 마이너와 유사하게 암호를 풀고 그 보상으로 검증자를 지지할 수 있는 집단입니다.
- Stakes와 Solutions의 비율
Stake와 Solution의 비율은 현재 60:40으로 유지하고 있습니다. 전체 Stake와 Solutions의 양은 매 분기(Term)마다 축적되며 네트워크를 Backing하는 비율은 해당 비율이 Expected Ratio와 일치할 때까지 수정됩니다.
- Proof of Intelligence
Proof of Intelligence는 참가자들로 Artificial Intelligence Computation을 하면서 Denial of service attack을 방지하기 위한 경제적 조치입니다. 참여자들이 미리 정해진 뉴럴 네트워크를 훈련하여 비슷한 결과(이전 N블록의 해시를 Input으로 하여 현재 블록의 Hash)를 만들어 냅니다.
Proof의 검증은 공급된 parameter vector에 의해 정의된 뉴럴 네트워크를 불러옵니다. 이전 N블록의 해시를 Feed해서 결과를 Run하고 Collect하면서 검증할 수 있습니다. 또한 Proof of intelligence는 PoW의 Pooling과 비슷하게 Proof of Intelligence내 Solvers들이 Parameter Subspace에서 독립적으로 일합니다. 즉, Proof of Intelligence 기존 채굴 과정과 유사하지만 뉴럴 네트워크를 통해 암호화된 문제를 해결하고 해결값을 바탕으로 검증자에게 투표를 할 수 있는 시스템입니다.
3. 합의 알고리즘
Aion-1은 Hybrid 프로토콜과 결합된 Byzantine Fault Tolerant에 기반한 합의 알고리즘을 사용하는데, 부분적으로 토큰 시스템과 신경 네트워크에서 사용되는 개념을 기반으로 하는 새로운 검증 알고리즘(Proof of Intelligence)을 활용합니다. 네트워크 참여자는 합의 과정에 참여하는 검증자를 지원할 수 있고, 전통적인 BFT 알고리즘 보다 더 많은 참여를 가능하게 합니다. 구체적으로 BFT기반 프로토콜은 설계가 완료되지 않았지만 향후에 시스템이 안전성과 Liveness를 보장하게 설계할 것 입니다.
Q: 어떻게 합의 알고리즘을 설계해야 안전성과 Liveness를 보장할 수 있는지 자세한 서술이 없습니다. 백서에 추가적인 논의가 없어 향후에 추가적인 발표를 Track 해볼 필요가 있습니다.
대표를 선정하는 것은 네트워크가 최적의 검증자를 선정해야 하는 유인책이기 때문에, 검증자들과 Backer(검증자를 지원한 사람)은 일정의 보상을 받습니다. 즉 네트워크의 자치 행동이 적절한 투표를 거쳐 보안을 유지할 것이라는 믿음을 가지고 있습니다. 모든 노드는 자신을 후보자로 하거나 후보자를 선택할 수 있고, 가장 높은 지원을 받은 후보자는 검증자로 선정됩니다. 검증자는 블록을 생성하고 그에 맞는 보상을 받습니다. 검증자는 일정 기간의 임기를 가지고 있으며 임기가 마무리 되기 전에 다음 검증자의 선발 과정을 거칩니다. 네트워크 사용자가 후보자들을 지원하거나 기존 검증자의 지원을 철회하면서 Live set(현 검증자 집단)는 업데이트 되고 기간이 끝나면 Static set(신규 검증자 집단)는 기존의 Live set를 덮어쓴다.(Overwrite)
- 검증자 선발 과정
누구나 검증자가 될 수 있고 Aion-1이 되려면 충분한 Stake를 가지고 있어야하고 충분한 Backing이 필요합니다. 검증자들은 명성 Mechanism을 가지고 있고, 후보 검증자들은 자신들의 명성을 기반으로 더 많은 지지를 받을 수 있습니다. 검증자와 Backer의 보상 비율은 Nomination 당시 검증자에 의해 제안되고, 검증자와 Backer가 모두 동의했을 때에 결정됩니다.
- 계층화 된 검증자 집단 (Tiered Active Set)
Active Set내에서 검증자는 총 후원을 받은 수에 따라 계층화 된 구조를 가집니다. 검증자들은 더 많은 지원을 받기 위해 노력하고, 지원자들은 활동을 하지 않는 검증자까지 포함하여 여러 검증 집단을 지원을 할 것입니다. 왜냐하면 미리 정의된 보상체계가 Backers들로 특정 검증자들을 후원하는 것에 대한 기회 비용을 평가할 수 있게 알려주기 때문에, Backers가 다양한 검증자를 지원하거나 본인이 검증자 후보가 되도록 유도하기 때문입니다.
- Incentive
악의적인 Backers들을 예방하기 위해 몰수 등의 처벌하는 것 대신에 네트워크에 의한 합의는 보상에 대한 기회를 제거합니다. 즉, 해당 Mechanism은 Zero-sum gain(한 명이 이익을 얻으면 누군가 손실을 얻어야 하는 상황)을 예방하고, 대신에 개인들이 개인의 행동의 결과에 대해서 이해하고 있고 도덕적인 행동(Virtuous Manner)을 하도록 유도합니다. 악의적인 행동은 검증자의 명성과 지지가 줄어들면서 네트워크에 의해서 감지되며, 악의적 행동에 대한 피드백을 즉시 받고 고치지 않으면 검증자 Active Set에서 제외됩니다.
- Duplicitous Action
악의적 행동은 검증자가 제출했던 모든 Stake를 일정기간 동안 잠그고(Lock) 즉시 합의 검증자 명단에서 제외하면서 처벌합니다. 검증자의 지지자들 중 Staker들은 그들의 지분(Stake)를 연장된 기간 동안 잠금 당하는 방법으로 처벌 받습니다. Solvers은 그들의 Proof-of-Intelligence Solution을 무효화(Invalidate)하면서 합의 검증자를 제거함으로써 처벌 받습니다.
- Inactivity
검증자의 활동 부재는 Tier System 내 계급을 강등시키면서 처벌하고 가장 낮은 단계의 Tier에 있을 경우에는 합의 과정에서 제외합니다.
- Reputation
과거의 행동과 통계를 바탕으로 만들어진 Reputation system은 네트워크 프로토콜의 한 부분으로 사용자들이 적절한 검증 후보자를 선택할 수 있도록 합니다. Reputation으로 포함되는 것은 다음과 같습니다.
Uptime(네트워크 내 총 활동 시간)
Total backing(총 지원과 해당 분기에 받은 지원으로 과거 활동에 대한 지표)
Centrality(Social Network내 타 노드들과 연결되어 정도를 나타낸 지표)
Transaction Origin(네트워크에 나타나는 첫 번째 거래로 그동안 거래량을 나타내는 지표)
Network Trust(P2P간 만족스러운 행동의 가치를 나타내는 지표)
Q: 대의 민주주의의 단점은 소수의 집단이 대중을 호도하거나 투표율이 낮은 문제를 가지는 데, 위의 시스템 설계는 인센티브를 통해 선한 행위를 할 것이라는 가정으로 설계를 하고 있습니다. 위의 시스템 상에서 나타날 수 있는 추가적인 변수를 고려하여 시스템의 개선이 필요합니다.
- Aion Virtual Machine(AVM)
AVM은 분산 네트워크 내에 개개인의 요구에 맞춘 Lightweight JVM 실행 환경으로, 블록체인과 Application사이에 추출(Abstraction)을 허용하여 네트워크를 연결하는데 주요한 기능을 제공합니다. 개개인의 요구에 맞췄다는 말은 Lightweight VM이 1)소비 측정의 목적과 2)Host Machine과의 분리를 위해 설계 되었습니다. 1)소비 측정을 하는 이유는 악의적 행동에 대한 가능성을 줄일 수 있습니다. 튜링 완전성 언어에서 예산 소모가 발생하여 로직을 실행하는 일을 무제한 반복할 수 없거나 Host machine을 파괴하는 방식으로 활동하거나 잘못된 시기의 행동(Faulty timing behaviour)으로 합의 알고리즘을 파괴하는 일을 예방합니다. 2)Host Machine과 분리된 환경은 Host Machine과 관련 없는 정보가 Chain Logic 상에서만 발생하여 Host Machine의 안전을 보장하고 Chain Logic에 자율성(Determinism)을 보장합니다.
- Chain-oriented concurrency(동시 실행) model
합의를 위해 상태 변화와 거래가 순차적으로 발생되는 블록체인 네트워크는 사용에 있어 순차적인 것으로 고려됩니다. 하지만 이는 많은 거래를 처리함에 있어서 병목현상을 유발하고, 이에 대한 해결책으로 병렬 처리가 있습니다. AVM은 Program 수준의 Concurrency(동시실행)을 지원하여 다차원 Chain Logic 프로그램을 병렬로 처리합니다. 위의 목표를 위해서 AVM은 확장가능하고 자동적으로 다차원 VM을 분류(Cluster)하고 계약들을 이 결정적 방법으로 처리될 수 있도록 계획합니다.
Q: 병렬 처리를 지원하는 방식에 대한 구체적인 설명이 부족합니다. 어떤 과정을 거쳐 병렬 처리를 할 수 있는지 그리고 병렬 처리를 했을 때 예상되는 도전은 무엇 인지에 대해서 더 서술할 필요성이 있습니다.
AVM 구조의 핵심은 가볍고(Lightweight), 기계 친화적이며(Machine-frinedly), 블록체인에 특화된 Bytecode 해석을 제공한다는 것입니다. 특히 분리된 VM Sandbox환경을 사용하여 AVM의 안정성(Stability)를 제공합니다. 또한 Full-featured 블록체인 개발 Kit로 기존 SDK(Software Development Kit)을 대체합니다. 현존하는 Bytecode 분석은 AVM bytecode에 적용 가능하고, AVM은 체인 로직에 적합한 Tool을 제공하여 상호운용성(Interoperability)을 활용(Leverage)합니다.
- Script Language
Aion Scripting Language는 AVM bytecode로 컴파일되고 AVM에 의해서 실행되며, Aion-1 Chain의 로직을 작성하는 데에 사용되고 잠재적으로 Network를 연결시키고 참여하는 데 활용됩니다. 블록체인의 구체적 기능을 개발하는데 고도로 최적화된 개발 라이브러리를 제공하기 위해서 블록체인 Runtime/Development Kit(BRE/BDK)를 제공합니다. 이는 트랜잭션, 이벤트 발생, 블록체인 관련 데이터 검색(Retrieve)및 블록체인 응용 프로그램 기능 뿐만 아니라 전통적인 개발에서 제공하지 않는 특별한 기능을 지원합니다.
- 보안성
National University of Singapore 연구 팀의 리서치에 따르면 Chain-logic 개발자들에 의한 실수는 주로 예상치 못한 Input 데이터, 예외적인 Runtime과 재진입후 예상치 못한 상태 변화로 인해 발생합니다. Aion의 언어는 해당 오류들의 가능성을 낮출 것입니다. Aion은 Input데이터를 Chain logic으로 보내기 이전에 검증하고 실행하기 이전에 Output data를 검증합니다. 또한 Aion Scripting 언어는 프로그래머들이 보안 패턴을 쉽게 설계하도록 사전/사후 조건과 Assertion기능을 제공합니다. 예외 상황은 Cahin Logic에 의해서 완전히 지원되며 Runtime동안의 배열 순서는 확인됩니다.
Q: 기존 스크립팅 언어와 비교했을 때 어떤 구체적인 장점과 단점이 있는지 자세히 서술하지 않아 타 스크립팅 언어와 성능 차이를 비교하기가 어렵습니다.
추가 자료
스크립트는 무엇인가요? : 한글버전 설명 , 영어 설명(Bitcoin Wiki)
