Celestia가 DA 모듈의 대표가 될까요?

출처: CryptoYC Tech

Celestia란 무엇인가

Celestia의 전신은 LazyLedger입니다. "데이터 가용성"에 특화된 인프라입니다. 물론 그것 자체가 하나의 체인이지만, 상태 계산 문제와는 관련이 없습니다. 따라서 여기에서 데이터 가용성의 중요성과 확장성의 관계와 같은 일련의 선험적 문제가 파생됩니다.

여기서 전통적인 블록체인의 데이터 문제를 살펴볼 필요가 있습니다. ETH를 예로 들면, 현재 대부분의 노드는 경량 노드로, 블록 생성은 책임지지 않고 블록을 검증하는 역할만 합니다. 그러나 검증하는 것은 블록 헤더뿐이므로, 블록 생산자가 올바르고 유효한 블록 헤더를 발표하지만 거래 데이터를 포함하지 않거나 은폐할 경우 데이터 가용성 문제가 발생할 수 있습니다. 경량 노드는 쉽게 속거나 무효 블록을 수용할 수 있습니다.

또한, 전체 노드가 경량 노드를 위해 데이터 가용성 증명 및 무효 블록의 사기 증명을 생성할 수 없기 때문에, 경량 노드는 블록 데이터 자체를 검증하기 위해 스스로 수행해야 합니다. 또는, 대부분의 데이터가 정직하고 신뢰할 수 있다고 가정해야 합니다.

명백히 안전을 위해 대부분의 노드가 모든 거래 데이터를 다운로드하고 데이터 가용성을 검증해야 한다면, 이는 확장성 문제를 초래합니다.

여기서 데이터 가용성의 두 가지 병목 현상을 발견할 수 있습니다:

• 가용성 증명: 다른 노드에게 이 블록의 데이터가 실제로 사용 가능한 것임을 알립니다.

• 사기 증명: 블록이 유효한지 여부입니다.

이것이 Celestia가 해결하고자 하는 두 가지 문제입니다.

어떻게 해결하는가

그렇다면 Celestia는 이 두 가지 문제를 어떻게 해결할까요? 간단합니다: 체인 상 실행을 포기하고 체인 상 상태 전환을 포기하며, 2차원 Reed-Solomon 오류 정정 코드와 전용 네임스페이스 머클 트리 구조를 통해 데이터의 가용성을 보장하고, 실행 부분은 최종 사용자에게 맡깁니다. 그래서 이 두 가지를 간단히 살펴보겠습니다.

2차원 R-S 오류 정정 코드

이것은 요약하자면, 어떤 정보를 전달할 때, 정보 자체뿐만 아니라 오류를 허용할 수 있는 여분의 정보를 추가하는 것입니다. 간단한 예를 들어보겠습니다:

• 예를 들어, 내가 다른 사람에게 1 2 3이라는 정보를 전달하고 싶지만, 정보 전달 과정에서 일부 정보가 손실되거나 오류가 발생할 수 있다는 것을 알고 있습니다. 그래서 다른 사람이 내가 전달한 정보를 최대한 정확하게 확인할 수 있도록 one two three을 전달하기로 선택합니다.

• 만약 다른 사람이 수신한 정보가 on, to, thee라면, 수신자가 내용 형식이 숫자라는 것을 알고 있다면, 원래 데이터가 1 2 3이라는 것을 높은 확률로 확인할 수 있습니다.

물론 여기에는 임계값 문제가 포함됩니다. 정보가 총 n개의 조각으로 나뉘어 있을 때, k개의 조각이 올바르게 전송되면 전체 정보가 복원될 수 있습니다. 즉, 성공적으로 전달된 정보 비율이 k/n보다 크면 됩니다. 표준 Reed-Solomon 오류 정정 코드에 따르면, 이 임계값은 50%입니다.

Celestia에 구체적으로 적용하면, 그들은 새로운 샘플링 방법인 2차원 샘플링을 제안했습니다. 정보를 가로 세로 수가 같은 2차원 조각으로 나눕니다. 사기 증명(데이터 가용성 증명)을 검증할 때, 경량 노드는 가로 또는 세로 데이터만 다운로드하면 됩니다. 이렇게 다운로드해야 할 데이터 양이 √N으로 줄어듭니다(데이터가 n*n 조각으로 나뉘어 있다고 가정).

물론 전체 데이터를 다운로드하지 않기 때문에, 경량 노드는 각 행과 각 열의 머클 트리 루트를 블록 헤더의 일부로 다운로드하여 검증해야 하며, 이를 통해 데이터의 최대 가용성을 보장합니다. 이렇게 Celestia 네트워크는 P2P 기반의 씨앗 다운로드 네트워크로 변모합니다. 적은 데이터로도 데이터의 가용성을 높은 확률로 확인할 수 있습니다.

네임스페이스 머클 트리

우리는 이더리움의 상태 업데이트가 전역적으로 동기화된다는 것을 알고 있습니다. 매번 상태 전환이 모든 주소의 상태를 업데이트합니다. 부적절한 예를 들어보면: 내가 이더리움에서 www.cryptoyc.com의 데이터를 업데이트했을 때, 노드는 cryptoyc의 데이터를 검증하는 것 외에도 관련 없는 데이터(예: www.123.com의 상태)도 업데이트하고 검증합니다. 명백히 이는 비합리적입니다.

따라서 Celestia는 데이터를 저장할 때 네임스페이스 머클 트리를 사용하여 최종 노드가 애플리케이션을 실행할 때 자신과 관련된 데이터만 다운로드하도록 합니다. 이더리움처럼 전체 블록 데이터를 다운로드할 필요가 없습니다. 따라서 이러한 구조를 통해 해당 기능의 노드는 최종 노드에 필요한 데이터 상태만 반환할 수 있습니다.

이 머클 트리의 상세 구조와 구성 규칙은 나중에 관심이 있을 때 다시 이야기하겠습니다. 요약하자면, 이 구조는 네임스페이스 해시(nsHash, 네임스페이스 식별자를 접두사로 하는 래퍼 해시)를 기본 데이터로 하며, 루트 노드는 모든 자식 노드의 관련 네임스페이스 데이터를 포함합니다(여기서 "관련"이라는 단어가 중요합니다). 구체적으로 저장되는 데이터는 JSON 형식입니다. nsHash는 minNs, MaxNs, hash(x) 세 요소로 구성됩니다.

• minNs: 그 루트 노드가 속한 자식 노드 중 최소 네임스페이스 식별자입니다.

• maxNs: 그 루트 노드가 속한 자식 노드 중 최대 네임스페이스 식별자입니다.

• hash(x): 자식 노드의 해시 값으로, 일반 블록과 유사합니다.

전체 구조는 이 예시 그림으로 표현할 수 있습니다:

백서: https://arxiv.org/pdf/1905.09274.pdf

전체 프로세스는 AR의 smartwave와 매우 유사합니다: 체인은 데이터 저장 및 합의를 담당하고, 실행은 최종 사용자에게 맡깁니다. 개발 언어에 제한이 없으며 실행 병목 현상이 없고, 노드가 데이터를 다운로드할 때 자신과 관련된 데이터만 다운로드할 수 있어 효율성을 높입니다.

하지만 두 가지의 차이점은 Celestia가 저장과 합의의 역할을 다시 분리했기 때문에 Celestia 네트워크에는 세 가지 역할이 있습니다: 합의 노드, 저장 노드, 클라이언트 노드.

역할 분담 및 기본 프로세스

Celestia의 역할 분담과 기본 운영 프로세스를 더 잘 이해하기 위해, 우리가 도달하고자 하는 목적에서 시작해야 합니다.

• 첫째, Celestia는 데이터 가용성과 상태 전환/계산을 분리하고자 합니다. 왜 합의라고 말하지 않느냐 하면, 합의 자체가 데이터 가용성과 진실성을 확인하기 때문입니다. 따라서 데이터 가용성과 다시 분리하기는 어렵습니다. 그렇지 않으면 블록체인이 아닙니다.

• 둘째, 자신이 필요한 정보만 다운로드하여 계산합니다. Celestia는 계산을 수행하는 노드가 계산을 수행할 때 자신이 필요한 정보만 검색하고 전체 블록체인 정보를 다운로드할 필요가 없기를 바랍니다.

• 데이터 완전성. 데이터가 파괴되었음을 발견할 수 있어야 합니다.

• 애플리케이션 상태의 주권 독립성. 두 번째 점과 유사하게, 실행 노드는 다른 관련 없는 애플리케이션의 정보를 실행할 필요가 없으며, 해당 애플리케이션의 의존 애플리케이션(예: 한 애플리케이션이 다른 결제 기능의 애플리케이션을 호출해야 하는 경우)을 제외하고는 실행할 필요가 없습니다.

그들의 목적을 알게 되면, 이제 그들의 분담을 살펴볼 수 있습니다.

• 블록체인의 합의를 보장하기 위해 전문 합의 노드가 있습니다.

• 데이터 가용성을 위해 전문 저장 노드가 있습니다.

• 위의 두 가지가 있으면, 실행 작업은 최종 사용자에게 맡겨지며, 이들은 실행 노드로 간주됩니다.

이러한 노드는 점대점의 망상 구조로 Celestia 네트워크를 구성합니다. 주의할 점은 실행 노드는 반드시 하나 이상의 저장 노드에 연결되어야 하며, 자신의 애플리케이션의 상태 전환을 수행해야 합니다.

여기서 검증 규칙에 대해 언급할 필요가 있습니다. 일반적으로 두 가지로 나뉩니다:

• 간단한 검증 규칙: 일반 블록체인의 검증 방법으로, 모든 정보 M을 다운로드하고 Root(M) = mRoot를 검증합니다. 검증이 true로 판별되면 M과 블록 헤더 h를 배포하고, 해당 M 데이터를 최소한 일정 시간 t'(네트워크 최대 지연) 동안 저장해야 하며, 다른 노드가 정보를 수신할 수 있도록 해야 합니다(다른 검증 노드 및 저장 노드 포함).

• 확률 검증 규칙: 이것이 Celestia가 주로 추천하는 2D Reed-Solomon입니다. 기본 원리는 위에서 이미 설명했습니다. 여기서 공식 예를 들어 효과를 살펴보겠습니다.

  오류 정정 코드의 임계값이 1/4일 때, 하나의 블록이 4096조각(64*64)으로 나뉘어지면, 각 노드는 단지 15개의 샘플만 다운로드하면 데이터가 가용하다는 것을 99%의 확률로 확인할 수 있습니다(구체적인 검증은 다른 순수 수학 논문에서 다룰 예정이며, 아직 읽어보지 않았습니다). 즉, 각 노드는 원래 데이터 조각의 0.4%만 다운로드하면 데이터의 가용성을 높은 확률로 추론할 수 있습니다.

  물론, 확률 검증 규칙은 모든 노드가 다운로드한 데이터의 총합이 반드시 이 오류 정정 코드의 임계값을 초과해야 합니다. 예를 들어 임계값이 50%라면, 모든 노드가 다운로드한 데이터의 총합은 원래 데이터 조각의 50% 이상(비중복)이어야 하며, 그래야 데이터 가용성이 확인되고 최종적으로 블록 생성에 참여할 수 있습니다.

이제 기본 구조를 이해했으니, 애플리케이션이 어떻게 작동하는지 살펴보겠습니다.

애플리케이션 노드는 어떻게 작동하는가

우선, 위에서 언급했듯이, 애플리케이션 실행은 최종 고객이 수행합니다. 이들은 이 네트워크에서 단순한 사용자일 뿐만 아니라 실행 노드이기도 합니다. 매개변수, 즉 해당 해시와 nid(네임스페이스 ID, 위의 특수 데이터 구조로, 자신 애플리케이션의 네임스페이스 관련 정보를 얻기 위해 다른 관련 없는 정보를 얻을 필요가 없습니다)를 전달하여 애플리케이션 실행 상태 전환에 필요한 모든 정보를 얻고, 체인 외부에서 실행한 후 데이터를 체인에 업로드하여 다른 실행 노드가 실행 결과를 얻을 수 있도록 합니다.

물론, Celestia는 실행 결과를 검증하지 않기 때문에 애플리케이션 논리를 위반하는 거래가 발생할 수 있습니다. 따라서 여기에는 새로운 함수 transition이 추가되며, 애플리케이션은 이 함수를 호출하여 상태를 반환하고, 이 상태를 통해 거래의 합법성을 확인합니다.

거래가 불법일 경우, 전체 거래는 원래 상태로 롤백됩니다. 합법적인 거래만 상태'를 반환합니다.

물론, 여기서 파생되는 문제는 애플리케이션 업그레이드입니다. 이 점은 사실 smartwave의 처리와 유사합니다: 만약 거래가 기존 애플리케이션과 다른 논리를 사용하여 거래가 진행되지 않는 경우, 해당 노드에서 실행되는 애플리케이션은 새로운 애플리케이션으로 간주됩니다. 따라서 원래 애플리케이션을 사용하는 다른 사람에게 영향을 미치지 않습니다. 즉, 하드 포크가 필요 없으며, 애플리케이션이 업그레이드하고 싶다면 로컬 실행 논리를 변경하고 새 애플리케이션으로 등록하기만 하면 됩니다. 하드 포크가 필요 없으므로 다른 애플리케이션에 영향을 미치지 않습니다.

또 다른 문제도 해결해야 합니다: 애플리케이션 간 호출은 어떻게 처리할까요?

애플리케이션 간 호출

상상해보세요, 도메인 등록 계약을 사용하여 요금을 지불하고 도메인을 구매한다고 가정해봅시다. 시장에 이미 많은 결제 도구 계약이 있기 때문에, 우리가 사용하는 도메인 등록 계약은 제3자의 결제 계약을 호출하여 이 비즈니스 프로세스를 완료합니다.

이때, Celestia의 방식에 따르면 문제가 발생합니다: 애플리케이션의 독립 주권으로 인해 각 애플리케이션의 상태는 서로 간섭하지 않지만, 우리의 도메인 등록 애플리케이션은 분명히 다른 애플리케이션에 간섭할 것입니다. 이때 어떻게 해야 할까요?

• 전제 조건 호출: A 계약을 완료하기 전에 B 계약을 먼저 완료해야 합니다(즉, B 계약의 상태를 수정해야 합니다). 이때 B 계약은 다른 계약이 호출할 수 있도록 전용 함수를 설정할 수 있습니다. 위의 도메인 등록 계약이 이에 해당합니다. 이러한 경우, Celestia는 A 계약을 실행할 때 A에 필요한 데이터뿐만 아니라 B의 데이터도 다운로드해야 하며, B를 실행한 후 A를 실행해야 합니다. A의 실행은 B의 상태에 의존하기 때문입니다. B 계약을 실행하는 노드는 A의 데이터를 다운로드할 필요가 없습니다. 왜냐하면 B의 실행은 A에 의존하지 않기 때문입니다.

• 후속 조건 호출: A 계약을 완료한 후 B 계약을 수정해야 합니다. 예를 들어 이메일 구독 서비스에서, 이메일을 구독한 후 다른 계약이 구독 서비스의 상태에 따라 이메일을 전송해야 합니다. 이때 B 계약은 실행할 때 A 계약을 다운로드해야 하며, A 계약을 실행한 후 B 계약을 실행해야 합니다. Celestia의 구상에서는 이러한 호출이 매우 드물어야 합니다. 왜냐하면 다른 애플리케이션의 상태를 직접 수정하는 것은 독립 주권의 본래 취지에 반하기 때문입니다. 이 경우에는 모든 데이터를 다운로드해야 할 수밖에 없습니다.

요약

이로써 Celestia의 주제가 모두 소개되었습니다. 우리는 Celestia가 smartwave와 매우 유사하다는 것을 발견할 수 있습니다. 또는 이는 현재 일반적인 블록체인 구조 외에 또 다른 구조인 완전 조합 가능한 구조입니다. 데이터 가용성만 보장하고 실행을 책임지지 않으며 검증하지 않으며, USB 드라이브처럼 즉시 사용할 수 있습니다. 필요한 곳에 가서 사용할 수 있습니다(중계 체인과는 다릅니다. 중계 체인은 상태 전환도 책임집니다).

본질적으로 크로스 체인 가능하며, 다양한 크로스 체인 원자 상호작용을 지원합니다(특수한 머클 트리가 JSON 정보를 저장하므로 내용에 대한 요구가 없습니다). AR보다 나은 점은 검증 유효성에 필요한 데이터 양이 훨씬 적다는 점입니다. 그래서 여전히 매우 유망합니다. 현재 불확실한 점은 토큰 경제입니다. 토큰 경제가 어떻게 될지 모르겠습니다.

물론, Celestia+Optimint와 Arweave+KYVE 중 누가 최종적으로 승리할지는 확실하지 않습니다. 왜냐하면 이 두 프로젝트 모두 필자가 매우 좋아하는 프로젝트이기 때문입니다. 정말 멋진 프로젝트입니다.

마지막으로, 비교 그림을 보며 Celestia의 개선이 얼마나 큰지 살펴보겠습니다.

백서: https://arxiv.org/pdf/1905.09274.pdf

정말 멋지네요!