Vitalik新文：SSF如何让以太坊单槽签名数稳定在8192次？
원래 제목: SSF 이후 슬롯당 8192개의 서명을 고수하는 방법과 이유
원저자: Vitalik Buterin, ETH 연구
원곡: Luccy, BlockBeats
편집자 주: SSF(Single Slot Finality)는 Single Slot Finality의 약자로 이더리움의 대기 시간을 크게 줄일 수 있는 방법을 제공합니다. 블록체인 합의 메커니즘 분야에서 최종성이란 거래나 블록이 취소 불가능하게 되어 변조되거나 되돌릴 수 없음을 의미합니다. 최종성을 달성하는 것은 이중 지출 및 기타 악의적인 활동의 위험을 제거하기 때문에 분산형 시스템의 신뢰와 보안에 매우 중요합니다.
SSF는 블록체인 합의 메커니즘에서 단일 시간 슬롯 또는 시간 단위가 완결된 것으로 간주될 수 있다고 제안합니다. 모든 검증인이 슬롯 승인 또는 서명에 참여할 수 있도록 하여 거래 확인 시간을 줄이고 전반적인 사용자 경험을 향상시킨다는 점에서 원래 이더리움 합의와 다릅니다.
Vitalik은 ETH 연구로 돌아와서 참여 검증인이 SSF 이후 슬롯당 2개의 서명을 갖도록 허용해야 하는 이유, 즉 8192개의 서명에 도달해야 하는 이유에 대해 논의했습니다. 동시에 그는 이 목표를 달성하는 방법에 대한 세 가지 가정을 제안했습니다. 전체 스테이킹, 2계층 스테이킹 및 순환 참여에서는 프로토콜의 보안을 유지하면서 슬롯당 서명 수를 보다 효율적으로 처리하는 방법을 분석하고 장단점, 프로토콜과 사용자에 미치는 영향에 대해 논의합니다. BlockBeats는 다음과 같이 원본 텍스트를 컴파일합니다.
이더리움과 대부분의 다른 지분 증명(최종성 포함) 시스템 간의 주요 차이점 중 하나는 이더리움이 매우 많은 수의 검증자를 지원하려고 노력한다는 것입니다. 현재 우리는 895,000명의 검증자를 보유하고 있으며 Zipf의 법칙 분석에 따르면 이는 수십 개에 해당합니다. 수천 명의 독립적인 개인 또는 단체. 이것의 목적은 분산화를 지원하고 모든 사람이 자신의 행동 능력을 포기하고 소수의 스테이킹 풀 중 하나에 통제권을 넘겨주도록 요구하지 않고 일반 사람들이 스테이킹에 참여할 수 있도록 하는 것입니다.
그러나 이 접근 방식을 사용하려면 이더리움 체인이 슬롯당 많은 수의 서명(현재 약 28,000개, SSF 이후 1,790,000개)을 처리해야 하며 이는 매우 높은 부하입니다. 이 부하를 지원하려면 다음과 같은 많은 기술적 희생이 이루어져야 했습니다.
증명이 여러 서브넷에 걸쳐 분할되는 복잡한 증명 전파 메커니즘, 해당 서명을 확인하기 위해 최적화된 BLS 서명 작업 등이 필요합니다.
현재로서는 이에 효과적으로 대처할 수 있는 명확한 양자 저항 대안이 없습니다.
뷰 병합과 같은 분기 선택 수정은 개별 서명을 추출할 수 없기 때문에 더욱 복잡해집니다.
너무 많은 서명을 SNARK하는 것은 어렵습니다. Helios는 동기화 위원회 서명이라는 특수한 추가 서명을 사용하여 실행해야 합니다.
슬롯 내에는 2개가 아닌 3개의 서브슬롯이 필요하므로 안전한 최소 슬롯 시간이 늘어납니다.
서명 집계 시스템은 언뜻 보면 합리적으로 보일 수 있지만 실제로는 전체 시스템에 퍼져 있는 시스템적 복잡성을 야기합니다.
게다가 목표도 달성하지 못한다. 스테이킹을 위한 최소 요구 사항은 여전히 32ETH이며, 이는 많은 사람들이 도달할 수 없는 수준입니다. 논리적인 분석의 관점에서 볼 때 모든 사람이 모든 슬롯에 로그인할 수 있게 하고 실제로 일반 사람들에게 스테이킹을 제공하는 시스템의 목표는 장기적으로 실현 불가능해 보입니다. 만약 이더리움의 사용자가 5억 명이고 그 중 10%가 스테이킹에 참여한다고 가정해 보겠습니다. , 이는 슬롯당 1억 개의 서명을 의미합니다. 정보 이론적 관점에서 볼 때 이 설계의 처리에는 슬롯당 최소 12.5MB의 여유 데이터 공간이 필요하며 이는 대략 전체 샤딩 목표와 동일합니다. 가능할 수도 있지만 스테이킹 자체가 데이터 가용성 샘플링에 의존하도록 요구하면 복잡성이 크게 증가합니다. 그럼에도 불구하고 전 세계 인구의 약 0.6%만이 스테이킹에 참여하고 있으며, 이는 그렇게 많은 서명을 확인하는 계산상의 문제도 포함하지 않습니다.
따라서 각 슬롯에서 점점 더 많은 수의 서명을 달성하기 위해 마법의 총알(또는 마법의 방탄)을 만들기 위해 암호화 전문가에게 의존하기보다는 철학적인 변화를 제안합니다. 즉, 우선 그러한 기대를 포기하는 것입니다. 이는 지분 증명 설계 공간을 크게 확장하고 많은 기술적 단순화를 허용하며 Helios가 Ethereum 합의에서 직접 SNARK를 수행할 수 있게 하여 더욱 안전하게 만들고 Winternitz와 같이 흥미롭지는 않지만 오래 지속되는 서명 체계도 만들 것입니다. 양자 저항 문제를 해결하는 것이 가능합니다.
왜 그냥 위원회를 사용하지 않습니까?
이 정확한 문제에 직면한 많은 비 이더리움 블록체인은 보안에 대한 위원회 기반 접근 방식을 채택합니다. 각 슬롯 동안 그들은 슬롯 마무리를 담당하는 N명의 검증인(예: N ≒ 1000)을 무작위로 선택합니다. 이 접근 방식은 책임을 제공하지 않기 때문에 왜 불충분한지 상기할 가치가 있습니다.
이유를 이해하기 위해 51% 공격이 발생한다고 가정해 보겠습니다. 이는 최종 상태 반전 공격일 수도 있고 검열 공격일 수도 있습니다. 공격을 수행하려면 공격에 동의하기 위해 대부분의 주식을 통제할 경제적 행위자가 필요합니다. 즉, 공격에 참여하는 소프트웨어를 실행하고 궁극적으로 모든 검증자와 함께 공격에 참여해야 합니다. 위원회에서 봉사하도록 선택되었습니다. 수학적 무작위 샘플링이 이를 보장합니다. 그러나 공격에 동의한 대부분의 검증인은 최종적으로 위원회에 선출되지 않아 모습을 드러내지 않았기 때문에 이에 대해 최소한의 처벌을 받았습니다.
현재 이더리움은 정반대의 일을 하고 있습니다. 51% 공격이 발생하면 전체 공격 검증자 세트의 대부분이 예치금을 삭감하게 됩니다. 현재 공격 비용은 약 900만 ETH(약 200억 달러)이며 공격자에게 가장 유리한 방식으로 네트워크 동기화 중단이 발생한다고 가정합니다.
비용이 많이 든다고 생각하지만, 이 문제에 대해서는 어느 정도 희생을 할 수 있을 만큼 비용이 너무 높습니다. 공격 비용이 100만 ~ 200만 ETH라고 해도 완전 충분합니다. 게다가 현재 이더리움에 존재하는 주요 중앙화 위험은 완전히 다른 곳에서 나타납니다. 즉, 최소 입금액이 0에 가깝게 줄어들더라도 대규모 스테이킹 풀의 힘은 크게 줄어들지 않을 것입니다.
이것이 제가 중간 솔루션을 옹호하는 이유입니다. 검증인의 책임을 일부 희생하되 삭감 가능한 ETH의 총량을 높게 유지하고 그 대가로 더 작은 검증인 세트의 이점을 대부분 누리는 것입니다.
SSF에서 슬롯당 8192개의 서명은 어떻게 되나요?
전통적인 2라운드 합의 프로토콜(Tendermint에서 사용하고 SSF에서 필연적으로 사용하는 것과 같은)을 가정하면 참여하는 각 검증인은 슬롯당 두 개의 서명이 필요합니다. 우리는 이러한 현실을 해결해야 하며, 이를 해결하는 세 가지 주요 방법이 있습니다.
방법 1: 분산형 서약 풀을 완전히 채택합니다.
Zen of Python에는 매우 중요한 문장이 포함되어 있습니다.
이를 수행하는 확실한 방법은 하나, 가급적이면 하나만 있어야 합니다.
스테이킹을 동일하게 만드는 문제와 관련하여 이더리움은 이 목표를 달성하기 위해 두 가지 다른 전략을 동시에 실행하고 있기 때문에 이 규칙을 위반합니다: (i) 소규모 독립적 스테이킹 및 (ii) 분산 검증 사용 가상 머신을 기반으로 하는 분산형 스테이킹 풀 기술(DVT). 위의 이유로 (i) 소수의 개인 스테이커만 지원할 수 있으며, 최소 입금액이 너무 높은 사람들이 항상 많이 있을 것입니다. 그러나 이더리움은 (i)를 지원하기 위해 매우 높은 기술적 부담 비용을 지불하고 있습니다.
한 가지 가능한 해결책은 (i)를 포기하고 (ii)에 올인하는 것입니다. 최소 입금액을 4096 ETH로 늘리고 총 검증인 한도를 4096(약 1670만 ETH)으로 설정할 수 있습니다. 소규모 스테이커는 자본을 제공하거나 노드 운영자가 되어 DVT 풀에 합류할 것으로 예상됩니다. 공격자의 남용을 방지하려면 노드 운영자 역할은 어떤 방식으로든 평판 임계값에 의해 제한되어야 하며, 개별 풀은 이와 관련하여 다양한 옵션을 제공하여 경쟁하게 됩니다. 자본 제공에는 라이선스가 필요하지 않습니다.
우리는 페널티 한도(예: 총 입금액의 1/8)를 설정하여 이 모델의 스테이킹을 더욱 관대하게 만들 수 있습니다. 이렇게 하면 노드 운영자에 대한 신뢰가 낮아질 수 있지만, 설명된 문제로 인해 주의해서 처리할 가치가 있습니다.
방법 2: 2중 서약
우리는 최종 상태 확인에 참여하기 위해 4096 ETH가 필요한 무거운 계층과 최소 요구 사항이 없는(예금 및 출금 지연 및 대폭적인 허점이 없는) 경량 계층이라는 두 계층의 스테이커를 만듭니다. 두 번째 계층 안전을 추가합니다. 블록의 최종 상태가 확인되기 위해서는 Heavy 레이어의 최종 상태 확인과 Light 레이어에 있는 온라인 라이트 검증자의 최소 50%가 이를 증명해야 합니다.
이러한 이질성은 검열 및 공격 저항에 유익합니다. 공격이 성공하려면 무거운 레이어와 가벼운 레이어가 모두 손상되어야 하기 때문입니다. 한 레이어가 손상되고 다른 레이어는 손상되지 않으면 체인이 중지되며, 상위 레이어가 손상되면 처벌될 수 있습니다.
이것의 또 다른 이점은 라이트 레이어에 인앱 담보로도 사용되는 ETH가 포함될 수 있다는 것입니다. 가장 큰 단점은 소규모 스테이커와 대규모 스테이커 사이에 구분을 설정하여 스테이킹을 덜 평등하게 만든다는 것입니다.
방법 3: 순환 참여(즉, 위원회이지만 책임이 있음)
우리는 여기에 제안된 슈퍼 위원회 설계와 유사한 접근 방식을 취합니다. 각 슬롯에 대해 현재 활성 유효성 검사기를 4096개 선택하고 각 슬롯에서 이 세트를 신중하게 조정하여 여전히 보안을 유지합니다.
그러나 우리는 이 프레임워크 내에서 가격 대비 가치를 얻기 위해 몇 가지 다른 매개변수를 선택했습니다. 특히, 검증인의 ETH 보유량이 임의적으로 높은 잔고로 참여할 수 있도록 허용하며, 검증인의 ETH 보유량이 일정 금액 M(변동적이어야 함)을 초과하는 경우 각 슬롯의 위원회에 참여합니다. 검증자가 N을 가지고 있는 경우
여기에 인센티브 목적의 가중치와 합의 목적의 가중치를 분리하는 흥미로운 레버가 있습니다. 평균 보상을 비례적으로 유지하려면 위원회의 모든 검증인에 대한 보상이 동일해야 합니다(적어도 ≤M ETH를 사용하는 검증인의 경우). 하지만 우리는 여전히 ETH 가중치를 통해 위원회의 합의 검증인 가중치를 계산할 수 있습니다. 이는 최종성을 깨기 위해 필요한 ETH의 양이 위원회의 총 ETH의 1/3배 이상과 동일하도록 보장합니다.
대략적인 Zipf의 법칙 분석을 통해 이 ETH 금액은 다음과 같이 계산됩니다.
총 잔액의 각 2차 수준에서 검증인의 수는 해당 잔액 수준에 반비례하며 이러한 검증인의 총 잔액은 동일합니다.
따라서 위원회는 검증인이 항상 위원회에 참여하는 장벽 M 위의 수준을 제외하고 각 잔액 수준에서 동일한 양의 ETH를 참여하게 됩니다.
참고: 계산된 데이터를 보다 명확하게 표시하기 위해 다음 단계가 스크린샷과 함께 표시됩니다.
이 접근 방식의 가장 큰 단점은 위원회 변경 시 합의 보안을 달성할 수 있도록 프로토콜에서 검증자를 무작위로 선택하는 복잡성이 약간 증가한다는 것입니다.
가장 큰 장점은 독립적인 스테이킹을 인식 가능한 형태로 유지하고, 단일 카테고리 시스템을 유지하며, 심지어 최소 입금액을 매우 낮은 수준(예: 1 ETH)으로 줄일 수 있다는 것입니다.
결론적으로
SSF 프로토콜 뒤에 있는 8192 서명을 고수하기로 결정하면 기술 구현자와 라이트 클라이언트와 같은 측면 인프라 구축자의 삶이 훨씬 쉬워질 것입니다. 누구나 합의 클라이언트를 실행하는 것이 더 쉬울 것이며, 사용자, 스테이킹 애호가 등은 이 가정에 따라 즉시 작업할 수 있습니다. 이더리움 프로토콜의 향후 로드는 더 이상 알 수 없습니다. 향후 하드 포크를 통해 개선될 수 있지만 개발자가 동일한 수준의 용이성으로 슬롯당 더 많은 서명을 처리할 수 있을 만큼 기술이 향상되었다고 확신하는 경우에만 가능합니다. .
나머지 작업은 위의 세 가지 접근 방식 중 어느 접근 방식을 택할지, 아니면 완전히 다른 접근 방식을 선택할지 결정하는 것입니다. 우리가 어떤 절충안을 만족하는지, 특히 현재 쉬워지고 있는 기술적인 문제와 별도로 해결될 수 있는 유동 스테이킹과 같은 관련 문제를 어떻게 처리하는지에 대한 질문이 될 것입니다.
IOS
Android