简体中文

繁體中文

English

Tiếng Việt

한국어

日本語

ภาษาไทย

Türkçe

Partnered With:

Avail: Polygon이 선보인 확장 가능한 데이터 가용성 레이어

DeFi之道

이 글을 읽으려면 19 분

Avail은 데이터 가용성을 중심으로 하는 범용적이고 확장 가능한 블록체인으로, 독립 체인, 사이드 체인 및 오프체인 확장 솔루션에 적합합니다.

원문 제목: "Polygon의 새로운 제품 Avail 이해하기: 확장 가능한 데이터 가용성 계층"

원문 작성자: Polygon

원문 출처: DeFi Road

Avail은 미래 블록체인 운영의 핵심적인 부분으로, Avail은 일반적이고 확장 가능하며 데이터 가용성 중심의 블록체인으로, 독립체인, 사이드체인 및 체인 외 확장 솔루션에 적합합니다.

Avail은 매우 안전한 수학 원천을 활용하여 강력한 데이터 가용성 계층을 제공하며, 데이터 가용성 확인에 사용되는 핵심적인 혁신을 갖추고 있습니다. 우리는 Kate 다항식 약속을 사용하여 부정 증명을 회피하고, 정직한 다수 가정이 필요하지 않으며, 데이터 가용성을 얻기 위해 정직한 풀 노드에 의존할 필요가 없는 2차원 데이터 가용성 방법을 만들었습니다.

Avail은 각기 다른 실행 환경에서 사용할 수 있는 일반적인 데이터 가용성 계층을 제공합니다. 장기적인 관점에서, Avail은 실행 환경 및 최종 구현 측면에서 다양한 실험을 지원할 것이며, 팀 및 프로젝트가 직접 자신의 보안을 시작할 필요가 없습니다. Polygon SDK, Cosmos SDK 또는 Substrate을 사용하여 생성된 체인은 Avail을 이용할 수 있습니다.

Avail은 거래 실행과 유효성을 공의 계층과 분리함으로써, 공의는 단지 a) 거래 정렬 및 b) 데이터 가용성 보증에만 책임을 집니다.

주요 목표

· 자체체인이나 사이드체인과 같은 임의의 실행 환경을 허용하여 거래 데이터 가용성을 보장함으로써 검증기 안전성을 이끌어내어 자체 검증기 집합을 만들고 관리할 필요성이 없도록 함

· Avail을 체인 외 데이터 가용성 계층으로 활용하여 Validium과 같은 Layer 2 솔루션이 더 높은 확장성 처리량을 제공하도록 함

2020년 말부터 우리는 Avail을 비밀리에 연구해 왔으며 현재 Devnet 단계에 있습니다. 테스트넷이 개발 중에 있습니다. 문제, 아키텍처 및 솔루션에 대한 자세한 정보 및 코드 참조는 참고 문서에서 찾을 수 있습니다.

배경

오늘날 Ethereum과 유사한 생태계에는 주로 세 가지 유형의 노드가 있습니다:

· 검증 노드

· 전체 노드

· 경량 클라이언트

하나의 블록은 밸리데이터 노드가 블록체인에 부착하며, 이 노드는 메모리 풀에서 트랜잭션을 수집하고 실행한 후 블록을 생성하기 전에 네트워크를 통해 전파합니다. 이 블록에는 해당 블록에 포함된 트랜잭션과 관련된 요약 및 메타데이터가 포함된 작은 블록 헤더가 포함됩니다. 전체 네트워크의 노드들은 이 블록을 받아들이고, 해당 블록에 포함된 트랜잭션을 다시 실행하여 그 유효성을 검사합니다. 경량 클라이언트는 인접한 전체 노드로부터 필요할 때만 블록 헤더와 트랜잭션 세부 정보를 가져옵니다. 블록 헤더의 메타데이터를 통해 경량 클라이언트는 수신한 트랜잭션 세부 정보의 진위를 확인할 수 있습니다.

이러한 아키텍처는 매우 안전하지만 일부 실제 제한이 있습니다. 경량 클라이언트는 전체 블록을 다운로드하지 않기 때문에 하위 데이터를 사용할 수 없는 블록을 수락하게 될 수 있습니다. 블록 생성자는 악의적인 트랜잭션을 블록에 포함할 수 있지만 전체 내용을 네트워크에 드러내지 않을 수 있습니다. 이를 데이터 가용성 문제라고 하며, 경량 클라이언트에게 심각한 위협으로 작용합니다. 더 나쁜 것은 데이터 무가용성이 소속할 수 없는 장애로, 우리가 데이터 손실에 대해 경고할 수 있는 부정행위 증명 구조를 추가할 수 없게 만든다는 것입니다.

기존 블록체인 대 Polygon Avail 비교

이에 비해 Avail은 이 문제를 해결하기 위해 다른 방식을 채택했습니다 — 앱 상태를 검증하는 대신 발행된 트랜잭션 데이터의 가용성과 트랜잭션 순서에 중점을 둡니다. 공증을 받은 블록은 해당 데이터가 가용할 때에만 유효하다고 간주됩니다. 이는 블록 생성자가 블록 헤더를 릴리스하지만 해당 데이터를 공개하지 않을 때의 상황을 방지하기 위함이며, 이는 클라이언트가 애플리케이션 상태를 계산하기 위해 필요한 트랜잭션을 읽는 것을 방지합니다.

Avail은 블록 검증 문제를 데이터 가용성 검증으로 단순화시켜, 이를 일정한 비용으로 효율적으로 완료할 수 있습니다. 데이터 가용성 검사는 데이터 버전 설계에서 널리 사용되는 파란 재드레식을 활용합니다.

데이터 가용성 검사는 각 경량 클라이언트가 체인의 각 블록에서 매우 작은 임의의 블록을 샘플링하도록 요구합니다. 이러한 방식으로 한 그룹의 경량 클라이언트가 전체 블록체인을 집적으로 샘플링할 수 있습니다. 좋은 생각 모델은 파일 공유 시스템인 Torrent와 같은 p2p 파일 공유 시스템입니다. 여기서 다른 노드는 일반적으로 파일의 일부분만 저장합니다.

이러한 기술은 Ethereum 2.0 및 Celestia(이전에는 LazyLedger로 불렸음)와 같은 시스템에서 광범위하게 사용될 예정임을 주의하십시오.

이로 인해 흥미로운 결과가 발생했습니다: 비합의 노드가 많을수록 안전하게 보유할 수 있는 블록 크기(및 처리량)가 커집니다. 이는 네트워크에서 비합의 노드도 네트워크의 처리량과 안전성에 기여할 수 있다는 것을 의미합니다.

KZG 기반 커밋먼트 스키마

Avail에서 사용되는 KZG 기반 커밋먼트 스키마에는 주로 다음과 같은 세 가지 특징이 있습니다:

· 데이터 중복으로 블록 생성자가 블록의 어떠한 부분도 숨기기 어렵게 만듭니다.

· 부정 보증이 가능한 올바른 삭제 코드

· 벡터 커밋먼트로 전체 노드가 가벼운 노드(include)에게 거래 포함을 설득하는 간결한 증명을 허용합니다.

간단히 말해, 블록의 모든 데이터가 2차원 행렬로 배열됩니다. 각 열에 대해 원본 열의 크기를 두 배로 늘리기 위해 행렬의 각 열에 소거 부호화를 수행하여 데이터 중복을 추가합니다. 각 행을 제출하기 위해 Kate 커밋먼트가 사용되며, 커밋먼트는 블록 헤더에 포함됩니다. 이 스키마는 데이터 은닉 시도를 쉽게 포착할 수 있도록 합니다. 왜냐하면 블록 헤더에만 액세스할 수 있는 어떤 가벼운 클라이언트도 행렬의 임의의 셀을 쿼리하고 블록 헤더를 기반으로 검사할 수 있는 간결한 증명을 얻을 수 있기 때문입니다(Kate 커밋먼트 덕분). 데이터 중복으로 인해 블록 생성자가 블록의 대부분을 숨기도록 해야 하므로 어떤 하나의 거래조차 숨기려는 경우라도 임의 샘플링으로 쉽게 포착됩니다. 우리는 부정 보증의 필요성을 피하며, Kate 커밋먼트의 제약력으로 인해 잘못된 커밋먼트를 구축해 대비한다면 계산적으로 매우 어려워 적발됨을 확인했습니다. 또한, KZG 커밋먼트 스키마의 유한성 속성을 사용하여 행의 커밋먼트를 계산 및 확장하는 것이 가능합니다.

KZG 커밋먼트 스키마

우리는 여기서 Avail 구성의 주요 기능을 언급했지만, 데이터 일부 검색 및 협력 가능성 보증과 같은 다른 기능도 있습니다. 우리는 여기서 세부 정보를 생략하고 후속 글에서 다시 다루겠습니다.

지금은 예시를 들고 실제 사용 사례를 연습하는 좋은 기회일 수 있습니다. 새로운 애플리케이션이 애플리케이션별 독립 체인을 호스팅하려는 상황을 가정해 봅시다. 이는 Polygon SDK나 다른 유사한 프레임워크(예: Cosmos SDK 또는 Substrate)를 사용하여 새 PoS 체인을 시작하고 비즈니스 로직을 내장하는 것입니다. 그러나 이는 충분한 보안성을 보증하기 위해 검증자 스테이킹을 통해 부트스트래핑 문제에 직면하고 있습니다.

이러한 상황을 피하기 위해 애플리케이션은 거래 순서화와 데이터 가용성을 위해 Avail을 활용합니다. 애플리케이션 사용자는 Polygon SDK 체인으로 거래를 제출하며, 이러한 거래는 자동으로 Avail로 전달되어 거기에서 순서가 지정되며 주문이 유지됩니다. 순서대로 된 거래는 하나(또는 여러 개)의 오퍼레이터에 의해 픽업되며 비즈니스 로직에 따라 최종 애플리케이션 상태가 구축됩니다. 애플리케이션 사용자는 순서화된 데이터가 사용 가능하며 Avail이 제공하는 강력한 안전 보증을 활용하여 언제든지 애플리케이션 상태를 재구성할 수 있기 때문에 안심할 수 있습니다.

위 예시는 Avail을 활용하여 안전성을 보장하는 새로운 독립적인 체인을 다루었지만, 이 플랫폼은 범용적이며 기존의 어떤 체인도 데이터 가용성을 보장하기 위해 사용할 수 있습니다. 다음 섹션에서는 Avail이 어떻게 기존 이더리움 집계 확장을 지원하는지 간단히 다룰 것입니다.

이더리움 체인 하위 확장 솔루션의 데이터 가용성에 대한 설명

다양한 이더리움 Layer 2 솔루션이 제안되었으며, Optimistic Rollup, ZK Rollup 및 Validiums와 같은 것들입니다. 이러한 솔루션은 실행을 체인 밖으로 옮기면서 애플리케이션 검증 및 데이터의 체인 상 가용성을 보장합니다. 체인 밖 실행 기반 아키텍처는 처리량을 향상시켰지만 여전히 이더리움과 같은 메인 체인이 처리할 수 있는 데이터 양에 제한을 받습니다. 왜냐하면 실행은 체인 밖에서 이루어지지만 검증 또는 분쟁 해결은 엄격히 체인 상에서 이루어지기 때문입니다. 거래 데이터는 후속 재구성을 위해 이더리움에 calldata로 제출되어야 하므로 데이터가 미래에 사용 가능하도록 보장됩니다. 이것이 매우 중요합니다.

Optimistic Rollup의 경우, 오퍼레이터는 잘못된 거래를 제출하고 전체 블록 일부를 연기할 수 있습니다. 이렇게 하면 시스템 내의 다른 풀 노드는 제출된 어설션의 정확성을 확인할 수 없습니다. 데이터 부족으로 인해 그들은 해당 어설션이 실제로 잘못되었음을 증명하는 어떠한 부정 표명/도전도 생성할 수 없게 됩니다.

제로 지식 기반 롤업의 경우 ZKP 강건성은 수락된 트랜잭션이 유효함을 보장합니다. 그러나 이러한 보증이 있더라도 트랜잭션을 지원하는 데이터를 노출하지 않으면 심각한 부작용이 발생할 수 있습니다.

이는 다른 확인자가 시스템의 현재 상태를 계산하지 못하게하고 사용자가 시스템에서 제외되어 잔액이 동결될 수 있음을 의미하며, 그들은 해당 잔액에 대한 액세스에 필요한 정보(증인)에 액세스 할 수 없습니다.

우리는 더 높은 처리량을 달성하기 위해 실행을 온체인에 위치시키는 것뿐만 아니라 데이터 가용성을 보장하기 위한 확장 가능한 데이터 호스팅 레이어가 필요함을 깨달았습니다.

이러한 블록체인 디자인은 다음 부분에 대한 해결책이 필요합니다:

· 데이터 호스팅 및 정렬: 이 부분은 트랜잭션 데이터를 수신하고 정렬한 다음 실행없이 데이터를 저장하고 분산 방식으로 완전한 데이터 가용성을 보장합니다. 이것은 Avail의 핵심입니다.

· 실행: 실행 구성요소는 Avail에서 정렬된 트랜잭션을 가져 와서 실행해야합니다. 이는 체크포인트/주장/증명을 생성하고이를 데이터 검증 레이어에 제출해야합니다. 우리는 이를 실행 레이어라고합니다.

· 검증/분쟁 해결: 이 부분은 시스템이 고정될 수있는 주체적 연결된 기본 체인을 나타냅니다. 설계된 보안성은이 부분의 강건성과 안전한 특성에 달려 있습니다. 실행 계층이 제출한 체크포인트/주장/증명은이 계층에서 처리되어 시스템이 유효한 상태 전환 만 수용하도록합니다(가용 데이터를 전제로). 이를 데이터 검증 레이어라고합니다.