세 가지 시각으로 AO의 파괴적 혁신 이해하기

AO는 전통적인 의미의 블록체인이 아닙니다. AO의 비정상적이고 비상식적인 설계는 AO를 처음 접하는 연구자들이 특정 지점에서 혼란을 겪기 쉽게 만듭니다. 특히 연구자들이 전통적인 블록체인 아키텍처로 AO를 정의하려고 할 때:

1. 비 PoS, 비 PoW, AO가 말하는 "홀로그램 합의"는 도대체 어떤 합의 메커니즘인가요?
2. 해시 체인이 없고, 블록도 없는 AO는 어떻게 데이터의 불변성을 보장하나요?
3. 조정 중심이 없는데, AO는 어떻게 전역 상태의 일관성을 보장하나요?
4. 중복 계산 메커니즘이 없는데, 누가 계산의 신뢰성을 보장하나요? 계산 오류가 발생하면 어떻게 하나요?
5. 공유 보안성이 없는데, 프로세스 간의 상호 운용성을 어떻게 보장하나요?

저는 3개의 관점을 통해 블록체인에서 이미 익숙한 개념을 사용하여 여러분이 알려진 것에서 미지의 세계로 넘어가고, 미지를 알려진 것으로 바꾸어 AO를 감성적으로 이해할 수 있도록 도와드리겠습니다.

분할 관점

이더리움 2.0, 폴카닷, Near와 같은 퍼블릭 체인의 교육을 통해 여러분은 "분할"이라는 개념에 익숙할 것입니다.

분할의 개념: 블록체인에서 분할은 네트워크 확장성을 높이기 위한 솔루션으로, 네트워크를 여러 개의 분할로 나누어 각 분할이 독립적으로 거래를 검증하고 처리하며 자신의 블록을 생성하여 전체 네트워크 효율성을 향상시킵니다. 분할 내에서는 동기식 상호 운용이 가능하고, 분할 간에는 특정 통신 프로토콜을 통해 비동기식 상호 운용이 이루어집니다.

폴카닷은 가장 전형적인 분할 아키텍처입니다. 폴카닷에서 각 평행 체인은 하나의 분할이며, 평행 체인은 독립적으로 자신의 블록체인을 수집하고 패키징하며, 중계 체인은 무작위로 검증자 그룹을 할당하여 검증합니다. 평행 체인 간에는 통일된 XCM 메시지 형식을 통해 통신하여 상호 운용을 실현합니다.

AO의 극한 분할

분할의 관점에서 AO는 극한의 "분할"로 이해될 수 있습니다: 각 프로세스는 하나의 분할입니다. 상상해 보세요, 이더리움의 각 스마트 계약이 개별 분할에서 실행된다면 어떤 모습일까요? 맞습니다, 이것이 AO입니다. 각 프로세스는 독립적이며, 프로세스 간의 호출은 메시지 기반으로 완전히 비동기적으로 이루어집니다.

모듈화 관점

하지만 우리는 폴카닷의 설계에서 "중계 체인"이 존재한다는 중요한 사실을 발견했습니다. ETH2.0에서도 "신호 체인"이 있습니다. 이들의 역할은 통일된 합의 층으로서 공유 보안을 제공하는 것입니다. 통일된 합의 층은 모든 분할 및 분할 간의 메시지 전달에 대해 직접 또는 간접적인 검증 서비스를 제공해야 합니다. 그러나 AO는 이 구성 요소가 없는 것 같습니다. 그렇다면 AO의 합의 층은 어떻게 설계되었을까요?

AO의 합의 층은 실제로 Arweave입니다. 모듈화 관점에서 이해할 때, AO는 Arweave의 L2로 이해될 수 있으며, Arweave를 L1으로 하는 롤업입니다. AO 네트워크 운영 과정에서 발생하는 모든 메시지의 로그는 Arweave에 영구 저장됩니다. 즉, Arweave에는 AO 네트워크 운영의 불변 기록이 존재합니다. 그렇다면 여러분은 질문할 수 있습니다. Arweave는 탈중앙화 저장 플랫폼으로, 많은 계산 능력을 갖추고 있지 않습니다. Arweave는 AO 네트워크에서 업로드된 데이터를 어떻게 검증하나요?

답은: Arweave는 검증하지 않습니다. AO 네트워크 자체에 낙관적 중재 메커니즘이 있습니다. Arweave는 AO 네트워크에서 업로드된 메시지 데이터를 거부하지 않으며, 각 메시지는 발신자 프로세스 ID와 이를 실행하는 CU(계산 단위)의 서명을 포함하고, 정렬을 위한 SU(정렬 단위)의 서명도 포함됩니다. 분쟁이 발생할 경우, Arweave의 불변 메시지 기록을 의존하여 더 많은 노드를 도입해 재계산을 수행하여 올바른 분기를 생성하고, 원래의 잘못된 분기는 폐기하며, 올바른 분기에서 오류가 발생한 CU 또는 SU의 보증금을 몰수합니다. 여기서 주의할 점은 MU는 프로세스의 대기 메시지를 수집하여 SU에 전달하는 역할을 하며, 신뢰가 필요 없고 보증금이 필요 없으며, 몰수와 관련이 없습니다.

AO는 Arweave를 L1으로 하는 낙관적 롤업과 매우 유사하지만, 검증 도전 과정은 L1에서 발생하지 않고 AO 네트워크 자체에서 발생합니다.

하지만 여기에는 여전히 문제가 있습니다. 모든 메시지가 Arweave에 수록된 후에야 확인할 수는 없습니다. 실제로 Arweave의 최종 확정성 형성 시간은 반 시간 이상 걸립니다. 그래서 AO는 자체적으로 소프트 합의 층을 가지고 있습니다. 이더리움의 롤업이 소프트 합의 층을 가지고 있는 것처럼, 대부분의 거래는 L1 확인을 기다리지 않고 즉시 장부에 기록됩니다.

AO의 프로세스는 실제로 검증 강도를 자율적으로 결정합니다.

메시지를 수신하는 프로세스는 Arweave의 확인을 기다린 후 해당 메시지를 처리할지, 소프트 합의 층의 확인 후 즉시 처리할지를 결정해야 합니다. 심지어 소프트 합의 층의 확인 단계에서도 프로세스는 유연한 전략을 취할 수 있습니다. 단일 CU가 확인한 후 즉시 처리할 수도 있고, 여러 CU가 중복 확인한 후 교차 검증을 통해 처리할 수도 있으며, 중복도 프로세스가 결정합니다.

실제 응용에서 검증 강도는 종종 거래 금액과 관련이 있습니다. 예를 들어:

소액 거래는 빠른 검증 전략을 사용하여 단일 확인 후 즉시 처리합니다.

중간 금액 거래는 구체적인 금액에 따라 다양한 중복 확인 후 처리 전략을 취합니다.

대액 거래는 신중한 검증 전략을 사용하여 Arweave 네트워크의 확인 후 처리합니다.

이것이 AO가 말하는 "홀로그램 합의" + "유연한 검증"의 모델입니다. "검증 가능성"과 "검증" 행위를 분리함으로써, AO는 합의 문제에 대해 전통적인 블록체인과는 완전히 다른 접근 방식을 취하며, 메시지 검증의 책임은 네트워크 자체가 아니라 수신자 프로세스 자체, 또는 애플리케이션 개발자에게 있습니다.

이러한 합의 모델을 채택했기 때문에 AO는 "극한 분할"의 무허브, 무한 확장 모델을 채택할 수 있습니다.

물론, 유연한 검증은 서로 다른 프로세스의 검증 강도가 다르게 되어 복잡한 상호 운용에서 신뢰 체인이 끊어질 수 있습니다. 긴 호출 체인에서 개별 단계의 실패는 전체 거래의 실패 또는 오류를 초래할 수 있습니다. 사실, AO 테스트넷 단계에서 이러한 문제는 이미 드러났습니다. 저는 AO가 모든 검증 작업에 대해 최소 검증 강도 기준을 설정해야 한다고 생각하며, AO의 공식 네트워크가 어떤 새로운 설계를 갖출지 기대해 봅니다.

자원 관점

전통적인 블록체인 시스템에서 자원은 "블록 공간"으로 추상화됩니다. 블록 공간은 노드가 제공하는 저장, 계산 및 전송 자원의 집합으로 이해될 수 있으며, 체인 상의 블록과 유기적으로 결합되어 체인 상의 애플리케이션에 실행의 매개체를 제공합니다. 블록 공간은 제한된 자원이며, 전통적인 블록체인에서는 서로 다른 애플리케이션이 블록 공간을 차지하기 위해 경쟁하고, 그에 대해 비용을 지불해야 하며, 노드는 이러한 비용을 통해 수익을 얻습니다.

AO에는 블록의 개념이 없으므로 자연스럽게 "블록 공간"의 개념도 없습니다. 그러나 다른 체인의 스마트 계약과 마찬가지로 AO의 각 프로세스는 실행 시 자원을 소모해야 하며, 거래 및 상태 데이터를 임시로 저장하기 위해 노드가 필요하고, 계산 작업을 수행하기 위해 노드가 계산 자원을 소모해야 하며, 발신한 메시지는 MU와 SU를 통해 목표 프로세스에 전달되어야 합니다.

AO에서는 노드가 세 가지 유형으로 나뉩니다: CU(계산 단위), MU(메시지 단위), SU(정렬 단위). 이 중 CU는 계산 작업을 수행하는 핵심입니다. MU와 SU는 통신 작업을 수행합니다. 프로세스가 다른 프로세스와 상호 작용할 필요가 있을 때, 메시지가 생성되어 출발 대기열에 저장됩니다. 해당 프로세스를 실행하는 CU는 메시지에 서명하고, MU는 출발 대기열에서 해당 메시지를 추출하여 SU에 제출합니다. SU는 메시지에 고유한 일련 번호를 부여하고 Arweave에 영구 저장합니다. 그런 다음 MU는 메시지를 목표 프로세스의 도착 대기열로 전달하여 메시지 전달을 완료합니다. MU는 메시지의 수집자 및 전달자로 이해할 수 있으며, SU는 메시지의 정렬자 및 업로더로 이해할 수 있습니다.

저장 자원에 관해서는, AO 네트워크의 MU는 계산에 필요한 임시 데이터만 저장하면 되며, 계산이 완료된 후에는 이를 폐기할 수 있습니다. 영구 저장을 담당하는 것은 Arweave입니다. Arweave는 수평 확장이 불가능하지만, 저장 성능의 한계가 매우 높습니다. AO 네트워크의 저장 요구는 가시적인 미래에도 Arweave의 한계에 도달할 수 없습니다.

우리는 AO 네트워크의 계산 자원, 전송 자원, 저장 자원이 모두 분리되어 있음을 발견했습니다. Arweave가 제공하는 통일된 저장 자원을 제외하고, 계산 자원과 전송 자원은 각각 수평 확장이 가능하며, 아무런 제한이 없습니다.

더 많은 고성능 CU 노드가 네트워크에 추가될수록 네트워크는 더 높은 계산 능력을 가지게 되어 더 많은 프로세스를 지원할 수 있습니다. 마찬가지로, 더 많은 고성능 MU, SU 노드가 네트워크에 추가될수록 네트워크의 전송 효율은 더욱 빨라집니다. 즉, AO의 "블록 공간"은 지속적으로 창출될 수 있습니다. 애플리케이션에 대해서는 공개 시장에서 공공 CU, MU, SU 노드 서비스를 구매할 수 있으며, 완전히 개인 노드를 운영하여 자신의 애플리케이션에 서비스를 제공할 수도 있습니다. 애플리케이션의 비즈니스가 확장되면, 자신의 노드를 확장하여 성능을 향상시킬 수 있습니다. 이는 전통적인 블록체인에서는 상상할 수 없는 일입니다.

자원의 가격 책정 측면에서 AO는 수요와 공급에 따라 유연하게 조정할 수 있으며, 따라서 자원의 공급은 수요에 따라 조정될 수 있습니다. 이러한 조정은 매우 민감하며, 노드의 추가 및 제거는 매우 빠르게 이루어질 수 있습니다. 이더리움을 다시 살펴보면, 자원 수요가 급격히 증가할 때, 사람들은 비싼 가스 요금을 감수하는 것 외에는 다른 선택이 없음을 알 수 있습니다. 이더리움은 노드 수를 늘려 성능을 향상시킬 수 없기 때문입니다.

요약

이상으로, 우리는 대부분의 암호화 연구자들이 익숙한 개념인 "분할", "모듈화", "롤업", "블록 공간" 등을 통해 AO의 원리와 메커니즘에 접근하여 AO가 어떻게 파괴적인 혁신을 통해 거의 무한한 확장을 이룰 수 있는지를 이해하는 데 도움을 주었습니다.

이제 처음의 몇 가지 질문을 다시 돌아보면, 여러분은 이미 이해하셨나요?

1. 비 PoS, 비 PoW, AO가 말하는 "홀로그램 합의"는 도대체 어떤 합의 메커니즘인가요?

AO의 합의 메커니즘은 실제로 Op Rollup에 가까운 설계입니다. 하드 합의 측면에서는 Arweave에 의존하고, 소프트 합의 측면에서는 각 프로세스가 검증 강도를 자율적으로 결정하고, 몇 개의 CU 노드가 중복 계산을 수행할지를 자율적으로 결정할 수 있습니다.

2. 해시 체인이 없고, 블록도 없는 AO는 어떻게 데이터의 불변성을 보장하나요?

Arweave에 업로드된 DA 데이터는 불변이며, AO의 모든 계산 및 전송 과정에 대해 검증 가능성을 제공합니다. AO는 단위 시간 내의 처리 용량을 제한할 필요가 없으므로 블록을 설정할 필요가 없습니다. "해시 체인"과 "블록"은 데이터의 불변성을 보장하기 위해 사용되는 구조이며, Arweave 체인은 이를 갖추고 있습니다.

3. 조정 중심이 없는데, AO는 어떻게 전역 상태의 일관성을 보장하나요?

각 프로세스는 독립적인 "분할"로, 거래와 상태를 독립적으로 관리하며, 프로세스는 메시지 기반으로 상호 작용합니다. 따라서 전역 상태의 일관성이 필요하지 않습니다. Arweave의 영구 저장은 전역 검증 가능성과 역사적 회귀 능력을 제공하며, 낙관적 도전 메커니즘과 결합하여 분쟁 해결에 사용될 수 있습니다.

4. 전역 강제 중복 계산 메커니즘이 없는데, 누가 계산의 신뢰성을 보장하나요? 계산 오류가 발생하면 어떻게 하나요?

AO는 전역적으로 강제되는 중복 계산 메커니즘이 없으며, 각 프로세스는 수신한 각 메시지의 신뢰성을 어떻게 검증할지를 자율적으로 결정할 수 있습니다. 계산 오류가 발생하면 낙관적 도전의 형태로 이를 발견하고 수정할 수 있습니다.

5. 공유 보안성이 없는데, 프로세스 간의 상호 운용성을 어떻게 보장하나요?

프로세스는 각 상호 운용하는 프로세스의 신뢰를 자율적으로 관리해야 하며, 서로 다른 보안 수준의 프로세스에 대해 서로 다른 수준의 검증 강도를 적용할 수 있습니다. 호출 체인이 복잡한 상호 운용의 경우, 신뢰 체인이 끊어지는 데 따른 높은 오류 수정 비용을 피하기 위해 AO는 최소한의 검증 강도 요구 사항을 설정할 수 있습니다.