블록체인 네트워크에서 노드는 새로 제안된 블록에 대한 모든 데이터가 사용 가능한지 어떻게 보장합니까? 이것이 왜 중요합니까?
이 글에서는 데이터 가용성 문제와 그것이 이더리움의 확장성에 어떤 영향을 미치는지 자세히 살펴보겠습니다.
데이터 가용성 문제는 무엇입니까?
데이터 가용성(DA) 문제: 블록체인 네트워크의 노드는 새로 제안된 블록의 모든 데이터가 실제로 사용 가능한지 어떻게 보장합니까? 데이터를 사용할 수 없는 경우 블록에는 블록 생산자가 숨긴 악의적인 거래가 포함될 수 있습니다. 블록에 악의적이지 않은 거래가 포함되어 있더라도 이를 숨기면 시스템 보안이 위협받을 수 있습니다.
예를 들어 Alice가 ZK-Rollup 운영자라고 가정합니다. 그녀는 이더리움에 ZK 증명을 제출했고 그것이 확인되었습니다. 그녀가 Ethereum에 모든 거래 데이터를 제출하지 않으면 롤업 사용자는 여전히 현재 계정 잔액에 대해 알지 못할 수 있지만 그녀의 증거는 롤업에서 이루어진 모든 상태 전환이 유효하다는 것을 확인합니다. 영지식 특성으로 인해 제출된 증거는 현재 상태에 대한 정보를 공개할 수 없습니다.
낙관적 롤업 시나리오에는 Alice가 Ethereum에 대한 주장을 제출했지만 거래 데이터를 사용할 수 없었기 때문에 OPR 참가자가 주장을 다시 계산하거나 이의를 제기할 수 없었던 유사한 예가 있습니다.
위의 상황에 대처하기 위해 OPR과 ZKR의 설계에서는 운영자가 모든 거래 세부 정보를 콜 데이터로 Ethereum에 제출하도록 요구합니다. 이를 통해 단기적으로는 DA 문제를 피할 수 있지만 롤업 내의 트랜잭션 수가 증가함에 따라 커밋해야 하는 데이터의 양도 늘어나 이러한 롤업이 제공할 수 있는 확장의 양이 제한됩니다.
더 나쁜 것은 데이터 가용성이 고유하게 발생하지 않는 오류라는 점입니다. 이는 참가자가 특정 데이터 블록이 누락되었음을 다른 노드에 증명할 수 없음을 의미합니다. 이는 Bob이 Alice가 제출한 블록에 데이터가 누락되었음을 알릴 수 있지만 Charlie가 Alice에게 쿼리하면 Bob이 그에게 데이터를 제공할 수 있기 때문입니다.
데이터 가용성 문제는 현재 블록체인에 어떤 영향을 미치나요?
이 질문에 답하기 위해 먼저 이더리움과 같은 블록체인의 일반적인 블록 구조와 블록체인 네트워크에 존재하는 클라이언트 유형을 검토해 보겠습니다.
블록은 두 가지 주요 부분으로 나눌 수 있습니다.
블록 헤더: 작은 블록 헤더에는 블록에 포함된 거래와 관련된 요약 및 메타데이터가 포함됩니다.
블록 본체: 모든 거래 데이터를 포함하며 블록의 주요 부분을 구성합니다.
기존 블록체인 프로토콜에서는 모든 노드가 전체 노드로 간주되며 전체 블록을 동기화하고 모든 상태 전환을 확인합니다. 트랜잭션의 유효성을 확인하고 블록을 저장하려면 상당한 리소스가 필요합니다. 장점은 이러한 노드가 잘못된 트랜잭션을 허용하지 않는다는 것입니다.
모든 거래를 확인하기 위한 리소스가 없거나 사용하고 싶지 않은 또 다른 범주의 노드가 있을 수 있습니다. 대신 그들은 블록체인의 현재 상태와 이와 관련된 일부 거래가 체인에 포함되어 있는지 이해하는 데 주로 관심이 있습니다. 이상적으로는 이러한 라이트 클라이언트가 유효하지 않은 거래가 포함된 체인에 의해 스푸핑되지 않도록 보호해야 합니다. 이는 실제로 소위 사기 증명을 사용하여 달성할 수 있습니다. 이러한 간결한 메시지는 특정 블록 본문에 유효하지 않은 트랜잭션이 포함되어 있음을 보여줍니다. 모든 풀 노드는 이러한 사기 증명을 생성할 수 있으므로 라이트 클라이언트는 정직하기 위해 특정 풀 노드를 신뢰할 필요가 없습니다. 블록 헤더에 대한 사기 증명이 가능한 경우 이를 수신할 수 있도록 보장하는 가십 네트워크에 잘 연결되어 있는지 확인하기만 하면 됩니다.
하지만 이 시스템에는 문제가 있습니다. 블록 생산자가 블록 뒤의 전체 데이터를 공개하지 않으면 어떻게 될까요? 이 경우, 풀 노드는 분명히 블록을 거부할 것입니다. 그들의 관점에서는 블록이 블록 본체와 함께 제공되지 않으면 블록도 아니기 때문입니다. 그러나 라이트 클라이언트는 블록 헤더 체인을 볼 수 있으며 누락된 데이터를 알아차리지 못할 수 있습니다. 동시에, 풀 노드는 사기 증명을 생성하는 데 필요한 데이터가 부족하기 때문에 사기 증명을 생성할 수 없습니다.
이 문제를 해결하려면 라이트 클라이언트가 데이터 가용성을 확인하는 메커니즘이 필요합니다. 이는 데이터를 숨기는 블록 생산자가 라이트 클라이언트를 설득하여 회피할 수 없도록 보장합니다. 이는 또한 블록 생산자가 부분 데이터를 공개하도록 강제하여 전체 네트워크가 협업 방식으로 전체 블록의 데이터에 액세스할 수 있게 합니다.
예를 들어 이 문제를 더 깊이 이해해 보겠습니다. 블록 생산자 Alice가 트랜잭션 tx 1, tx 2, ..., txn을 포함하는 블록 B를 구성한다고 가정합니다. tx 1이 악의적인 거래라고 가정합니다. tx 1이 브로드캐스트되면 모든 풀 노드는 그것이 악의적인지 확인하고 사기 증명으로 이 정보를 라이트 클라이언트에 보낼 수 있으며 라이트 클라이언트는 해당 블록이 허용되지 않는다는 것을 즉시 알게 됩니다. 그러나 Alice가 tx 1 을 숨기고 싶다면 헤더와 tx 1 을 제외한 모든 거래 데이터만 공개합니다. 풀 노드는 tx 1의 정확성을 확인할 수 없습니다.
간단한 해결책은 모든 라이트 클라이언트가 트랜잭션을 무작위로 샘플링하게 하고, 샘플이 사용 가능하다는 것을 알게 되면 블록이 사용 가능하다고 확신할 수 있다고 생각할 수도 있습니다. 그러나 라이트 노드가 무작위로 트랜잭션을 쿼리하는 경우 라이트 클라이언트가 tx 1을 쿼리할 확률은 1/n입니다. 따라서 Alice는 거의 항상 라이트 클라이언트를 속여 악의적인 거래를 수락하도록 할 수 있습니다. 즉, 대부분의 라이트 클라이언트는 스푸핑됩니다. 귀속 불가능 특성으로 인해 전체 노드는 tx 1을 사용할 수 없음을 어떤 방식으로도 증명할 수 없습니다. 불행하게도 표본 크기를 늘려도 상황이 나아지는 것은 아닙니다.
그렇다면 이 문제를 어떻게 해결합니까?
이 문제에 대한 해결책은 블록에 중복성을 도입하는 것입니다. 이 문제를 해결하는 데 도움이 될 수 있는 코딩 이론, 특히 삭제 코딩에 대한 풍부한 문헌이 있습니다.
간단히 말해서 삭제 코딩을 사용하면 n개의 데이터 블록을 2n개의 데이터 블록으로 확장할 수 있습니다. 즉, 2n개의 n개 중 어느 것이든 원본 데이터를 재구성하는 데 충분합니다(매개변수는 조정 가능하지만 여기서는 간단하게 유지하고 이 상황을 고려합니다).
블록 생산자가 트랜잭션 tx 1, tx 2, ..., txn을 삭제하도록 강제한다면 단일 트랜잭션을 숨기려면 n+ 1개의 데이터 블록을 숨겨야 합니다. 왜냐하면 n개의 데이터 블록이 전체 트랜잭션을 구축하는 데 충분하기 때문입니다. 세트. 이 경우, 적은 수의 쿼리로 라이트 클라이언트에게 기본 데이터가 실제로 사용 가능하다는 높은 수준의 확신을 줄 수 있습니다.
Woah,그게 다야?
아니요. 이 간단한 트릭으로 인해 데이터를 숨기는 것이 더 어려워지지만, 블록 생산자가 의도적으로 잘못된 방식으로 삭제 코딩을 수행했을 가능성은 여전히 있습니다. 하지만 풀 노드는 이 삭제 코딩이 올바르게 이루어졌는지 확인할 수 있고, 그렇지 않은 경우 이를 라이트 클라이언트에게 증명할 수 있습니다. 이는 위에서 언급한 악의적인 거래와 마찬가지로 또 다른 유형의 사기 증명입니다. 흥미롭게도, 블록이 악의적일 경우 사기 증명을 받을 수 있도록 라이트 클라이언트의 이웃으로서 하나의 정직한 풀 노드만 있으면 됩니다. 이를 통해 라이트 클라이언트는 매우 높은 확률로 악의적인 거래가 없는 체인에 액세스할 수 있습니다.
하지만 문제가 있습니다. 너무 간단하게 수행하면 일부 사기 증명은 블록 자체의 크기만큼 커질 수 있습니다. 라이트 클라이언트에 대한 우리의 자원 가정은 그러한 디자인을 사용하는 것을 금지합니다. 약속 규모를 늘리는 대신 사기 증명 규모를 줄이는 다차원 삭제 코딩 기술을 사용하여 개선이 이루어졌습니다. 간결함을 위해 여기서는 이에 대해 자세히 다루지 않지만 이 기사에서는종이이를 자세히 분석했습니다.
사기 증명에 기반한 솔루션의 문제점은 라이트 클라이언트가 아직 사기 증명을 받지 못한 블록에 대해 완전히 확신할 수 없다는 것입니다. 동시에 그들은 계속해서 자신의 전체 노드를 정직하게 신뢰합니다. 또한 정직한 노드는 지속적으로 블록을 검토하도록 인센티브를 받아야 합니다.
여기서 초점을 맞추는 것은 블록 인코딩이 유효하지 않은 경우 전체 노드가 이를 감지하고 라이트 클라이언트에 증거를 제공하여 잘못된 행동을 확신할 수 있도록 보장하는 시스템입니다. 그러나 다음 섹션에서는 유효한 인코딩만 체인에 제출되도록 보장하는 블록 인코딩에 중점을 둘 것입니다. 따라서 코딩 오류를 입증하는 사기 증명이 필요하지 않습니다. 유효성 증명에 기반한 솔루션을 사용하면 애플리케이션은 전체 노드가 사기 증명을 제공할 때까지 기다리지 않고도 시스템을 사용할 수 있습니다.
그렇다면 이러한 솔루션은 어떻게 작동합니까?
최근 다항식 약속이 블록체인 공간에 대한 새로운 관심을 불러일으켰습니다. 이러한 다항식 약속, 특히 다항식에 대한 일정한 크기의 KZG/Kate 약속은 사기 증명이 필요하지 않은 깔끔한 데이터 가용성(DA) 체계를 설계하는 데 사용될 수 있습니다. 간단히 말해서, KZG 약속을 통해 단일 타원 곡선 그룹 요소를 사용하여 다항식을 사용할 수 있습니다. 더욱이, 이 방식을 사용하면 일정한 크기의 증인을 사용하여 어떤 지점 i에서 다항식 ψ가 ψ(i) 값을 갖는다는 것을 증명할 수 있습니다. 이 약속 체계는 계산적으로 구속력이 있고 동형이므로 사기 증명을 깔끔하게 피할 수 있습니다.
우리는 블록 생산자가 원시 거래 데이터를 nxm 크기의 2차원 행렬로 배열하도록 강제합니다. 다항식 보간법을 사용하여 n 크기의 각 열을 2n 크기의 열로 확장합니다. 이 확장 매트릭스의 각 행은 다항식 약속을 생성하며 이러한 약속은 블록 헤더의 일부로 전송됩니다. 블록의 도식적 표현은 다음과 같습니다.
라이트 클라이언트는 이 확장 매트릭스의 모든 셀에 증명을 요청하여 블록 헤더에 대해 즉시 확인할 수 있습니다. 일정한 규모의 멤버십 증명을 통해 샘플링이 매우 효율적으로 이루어집니다. 약속의 동형 특성은 블록이 올바르게 구성된 경우에만 증명을 확인할 수 있도록 보장하는 반면, 다항식 보간법은 일정한 수의 성공적인 샘플이 보장되어 데이터 가용성 확률이 매우 높다는 것을 의미합니다.
블록의 도식적 표현
이 계획의 더 자세한 내용과 추가 최적화 및 비용 추정은 이 기사의 범위를 벗어납니다. 그러나 여기서는 2차원 방식에 대해 논의하고 있지만 블록 헤더 크기가 더 작지만 병렬성과 빛의 양이 줄어드는 1차원 방식에서도 유사한 보장이 제공될 수 있다는 점을 지적하고 싶습니다. 클라이언트 샘플링 효율성. 이에 대해서는 다음 기사에서 더 자세히 살펴보겠습니다.
다른 대안은 무엇입니까? 다음에는 어떻게 되나요?
고차원 삭제 코딩 및 KZG 약속은 데이터 가용성 문제에 대한 유일한 솔루션이 아닙니다. 여기서는 코딩된 Merkle 트리, 코딩된 인터리브 트리, FRI 및 STARK 기반 방법과 같은 몇 가지 다른 방법을 생략했지만 각 방법에는 장점과 단점이 있습니다.
Avail에서는 KZG 약속을 사용하여 데이터 가용성 솔루션을 개발해 왔습니다. 후속 기사에서는 구현 세부 사항, 사용 방법, 데이터 가용성 문제 공간을 변경하는 방법을 다룰 것입니다. Avail에 대해 자세히 알아보려면 Twitter에서 팔로우하고 Discord 서버에 참여하세요.
Twitter：https://twitter.com/AvailProject
Discord：https://discord.com/invite/jTkvDrZ54r
Modular 101의 Twitter 계정(@Modular 101)을 팔로우하실 수도 있습니다.
