대중 과학: 데이터 가용성 문제
이미지 설명
-네...그 가스비로 거래를 완료하려면 며칠이 걸릴 것입니다-
Ethercat은 대규모 성공을 달성한 최초의 분산 응용 프로그램입니다. 그러나 그것(및 다른 응용 프로그램)은 이더리움 네트워크의 모든 리소스를 점유하여 체인의 멤풀이 전례 없는 속도로 증가했습니다. 하룻밤 사이에 사람들은 확장성 문제에 대한 해결책으로 플라즈마 및 상태 채널에 대해 이야기하기 시작했습니다. 그러나 토론과 흥분에도 불구하고 이러한 솔루션의 개발은 어려움을 겪었고 일부 커뮤니티 구성원은 실행 가능성을 의심하게 되었습니다. 그러나 이제 이러한 솔루션이 점차 온라인화됨에 따라 사람들은 오랫동안 개발자를 괴롭혀 온 실제 문제가 명백한 데이터 가용성 문제라는 것을 깨닫습니다.
보조 제목
데이터 가용성 문제
이전에 Vitalik이 설명했듯이 데이터 가용성 문제의 원인은 악의적인 채굴자가 블록 헤더가 있는 블록을 게시하려고 시도하지만 데이터의 일부 또는 전부를 체인에 손실한다는 것입니다. 이 공격은 다음과 같은 결과를 초래할 수 있습니다.
유효하지 않은 블록을 수락하도록 네트워크를 속이면 블록의 무효성을 증명할 방법이 없습니다.
노드가 현재 상태를 가져오는 것을 방지합니다.
노드가 증명을 구성할 해당 정보가 부족하여 블록을 생성하거나 자금을 이체하지 못하도록 합니다.
그러나 데이터 가용성은 블록 데이터를 숨기는 것만이 아닙니다. 일반적으로 말하면 일부 행위자(검토 메커니즘이라고도 함)가 일부 데이터에 액세스하지 못하도록 숨기는 한 데이터 가용성 문제라고 할 수 있습니다. 우리가 아는 한 이것은 메인넷에서 문제가 되지 않지만 매우 비쌉니다. 사실 지난 18개월 동안 각 이더리움 노드에 저장된 상태의 양이 6.5배 증가했습니다(빠른 동기화가 켜진 geth 소프트웨어 사용).
분명히 이것은 진정으로 분산된 웹에서는 지속 가능하지 않습니다. 블록체인의 크기가 계속 커짐에 따라 네트워크에 참여하고 노드 역할을 할 수 있는 컴퓨터의 수는 계속 줄어들 것입니다. 그렇다면 이 상황에 어떻게 대처해야 할까요?
예예
포커를 하기 위해 카지노에 간다고 가정하면 처음에는 카운터에서 달러를 포커 칩으로 교환합니다(이 프로세스를 온체인 트랜잭션으로 생각하십시오). 그런 다음 테이블에 앉아 몇 시간 동안 포커를 하기 시작합니다(오프체인 거래라고 함). 때때로 돈을 벌고 다른 때는 돈을 잃습니다. 큰 손에서 승리한 후 칩을 현금화하고 싶다고 하우스에 알립니다.
그러나 당신이 일어나면 누군가 당신의 뒤통수에 수액을 줍니다 - 당신은 흐릿한 기억과 함께 일어나 포커 핸드의 세부 사항을 기억할 수 없습니다("데이터를 사용할 수 없음"). 당신이 거기에 없을 때, 포커 테이블은 마지막 판이 일어나지 않은 것처럼 가장하기로 결정하고 그 판에 이르는 순간에 계속 플레이합니다. 즉, 당신이 이겼어야 할 돈에서 당신을 속이는 것입니다.
보조 제목
실제로
플라즈마에서 각 참가자는 자신의 암호화 자산이 각 플라즈마 블록에서 거래되었는지 여부를 증명할 수 있는 완전한 거래 내역과 충분한 증인 데이터를 유지해야 합니다. 이것은 각 참가자를 플라즈마 시스템의 노드로 만들지 만 자신의 트랜잭션 데이터만 저장합니다. 이 요구 사항은 Plasma에서 누구나 체인 운영자와 결탁하고 유효하지 않은 트랜잭션을 제출하여 다른 사람의 자산을 훔칠 수 있기 때문에 만들어집니다. 참가자가 이러한 일이 발생하지 않도록 하는 유일한 방법은 모든 자산의 완전하고 유효한 거래 내역을 보유하고 있는지 확인하는 것입니다.
상태 채널은 모든 참가자가 상태 업데이트(예: 트랜잭션)가 아닌 현재 상태에만 동의하기 때문에 데이터 요구 사항이 낮습니다. 이와 같이 거래내역을 재계산하지 않고 단 한번의 거래로 계약을 정산할 수 있다. 또한 각 상태에는 자동으로 증가하는 nonce가 있고 스마트 계약은 양 당사자가 서명하지 않는 한 유효한 상태로 간주하지 않기 때문에 참가자는 최신 상태만 저장하면 됩니다.
해결책
해결책
현재 관련 팀은 클라이언트가 유지 관리하거나 ZK-SNARKS 또는 RSA 누산기와 같은 것을 통해 메인넷에 제출해야 하는 데이터가 차지하는 공간을 줄이기 위해 최선을 다하고 있습니다. 이는 큰 개선이지만 할 수 없습니다. t 수정 데이터 가용성 문제. 사실, 우리는 단일 클라이언트에 대해 이 문제를 해결할 수 없습니다. 왜냐하면 클라이언트가 100% 온라인 상태여야 하고 저장된 데이터를 잃지 않아야 하기 때문입니다(블록체인처럼 들리지 않습니까? ?) .
그러나 그렇게 할 수 있는 하드웨어가 존재하지 않는다는 점을 감안할 때 데이터 가용성 문제에 대한 해결책은 인센티브가 있는 감시탑 네트워크(예: PISA) 또는 유사한 구조라고 널리 알려져 있습니다. 이러한 인센티브 네트워크는 실제로 유료 사용자를 위해 데이터를 백업하고 사용자가 분쟁할 수 없을 때(즉, 오프라인으로 전환) 사용자를 대신하여 의심스러운 거래에 이의를 제기하는 스테이크 감시탑 그룹입니다. 특정 시간 내에 챌린지에 이의를 제기하지 못하면 지분을 잃게 되며 해당 지분은 챌린지에 참여한 네트워크의 새로운 감시탑에 수여됩니다(실제로 챌린지를 제출했다고 가정). 이 버그/예약 프로토콜에는 여러 계층이 있으므로 사용자는 오프라인 상태가 되거나 트랜잭션/상태 기록이 손실될 경우 속지 않을 것임을 확신할 수 있습니다.
보조 제목
SKALE의 솔루션
SKALE의 탄력적 사이드체인은 블록 제안 프로세스를 통해 데이터 가용성 문제를 해결합니다. 유효성 검사기가 블록 제안을 생성한 후 아래에 설명된 데이터 가용성 프로토콜을 사용하여 다른 유효성 검사기와 통신합니다. 이 프로토콜은 블록 제안이 대다수(>⅔)의 검증자에게 전송되도록 합니다.
5단계 프로토콜은 다음과 같이 설명됩니다.
블록을 보내는 유효성 검사기 A는 블록 제안과 제안 P를 구성하는 모든 트랜잭션의 해시를 모든 동료에게 보냅니다.
P 및 관련 해시 값을 수신한 후 각 해당 노드는 P를 재구성하기 위해 패키징할 로컬 트랜잭션 대기열의 전송과 해시 값을 일치시킵니다. 대기열에서 찾을 수 없는 전송의 경우 노드는 전송을 보낸 검증자 A에게 조회 요청을 보냅니다. 그런 다음 발신 유효성 검사기 A는 이러한 트랜잭션의 본문을 수신 유효성 검사기로 전송하여 피어가 블록 제안을 재구성하고 이를 제안 스토리지 데이터베이스 PD에 추가할 수 있도록 합니다.
그 후 노드는 A에게 임계값 서명이 있는 영수증을 보냅니다.
노드(A 자체 포함)에서 노드의 절대 다수(2/3 이상)의 서명을 수집한 후 A는 절대 다수 서명 S를 생성합니다. 이 서명은 대다수의 검증자가 P를 소유하고 있다는 증거가 됩니다.
A는 이 절대다수 서명 S를 다른 모든 검증자에게 브로드캐스트합니다.
참고: 각 유효성 검사기는 BLS 개인 키 슬라이스 PKS[I]를 소유합니다. 키 슬라이스의 초기 상태는 Federated Feldman Distributed Key Generation(DKG) 알고리즘을 사용하여 수행되며 탄력적 사이드체인이 생성될 때와 유효성 검사기가 무작위로 교환될 때마다 실행됩니다. 자세한 내용은 BLS 및 DKG에 대한 기사를 확인하십시오!
요약하다
요약하다
대체로 실행 계층에서 솔루션 작업을 하는 개발자가 지난 18개월 동안 무엇을 했는지 궁금하다면 처음에 이 문제를 해결하는 데 대부분의 시간을 할애했을 가능성이 큽니다. 아직 모든 확장 문제에 대한 완벽한 해결책은 없지만 새롭고 흥미로운 작업이 많이 진행되고 있으며 앞으로 달성할 수 있는 것에 대해 매우 확신합니다!
