원문 편집: 남봉
원문 편집: 남봉
그러나 이 목표의 과제 중 하나는 복잡성을 정의하기 어렵고 때로는 서로 다른 종류의 복잡성을 도입하고 비용이 다른 두 가지 옵션 사이에서 절충해야 한다는 것입니다. 우리는 어떻게 비교합니까?
복잡성에 대해 더 세밀하게 생각할 수 있게 해주는 강력하고 지능적인 도구는 캡슐화된 복잡성과시스템 복잡성(systemic complexity)。
"캡슐화된 복잡성"은 시스템의 하위 시스템이 내부적으로 복잡하지만 외부에 간단한 "인터페이스"를 제공할 때 발생합니다. "시스템 복잡성"은 시스템의 서로 다른 부분이 명확하게 분리되지 않고 서로 복잡한 상호 작용을 할 수 없을 때 발생합니다.
다음은 몇 가지 예입니다.
BLS 서명 대 Schnorr 서명
BLS 서명과 Schnorr 서명은 타원 곡선으로 구성될 수 있는 일반적으로 사용되는 두 가지 암호화 서명 체계입니다.
BLS 서명은 수학적으로 매우 단순해 보입니다.
H는 해시 함수, m은 메시지, k와 K는 개인 및 공개 키입니다. 지금까지는 간단합니다. 그러나 실제 복잡성은 전자 함수의 정의에 숨겨져 있습니다. 타원 곡선 쌍은 모든 암호화에서 가장 이해하기 어려운 수학적 부분 중 하나입니다.
이제 Schnorr 서명을 살펴보겠습니다. Schnorr 서명은 기본 타원 곡선에만 의존합니다. 그러나 서명 및 확인 논리는 좀 더 복잡합니다.
예를 들어:
예를 들어:
BLS 다중 서명(두 키 k1 및 k2의 결합된 서명)을 수행하는 것은 간단합니다. σ1+σ2입니다. 그러나 Schnorr 다중 서명에는 두 번의 상호 작용이 필요하며 일부 까다로운 키 취소 공격을 처리해야 합니다.
Schnorr 서명은 난수를 생성해야 하지만 BLS 서명은 그렇지 않습니다.
보조 제목
암호학 대 암호경제학
많은 블록체인 설계에서 발생하는 중요한 설계 선택은 암호화와 암호 경제학 간의 비교입니다. 이것은(롤업에서와 같이) 종종 유효성 증명(예: ZK-SNARK)과 사기 증명 사이에서 선택됩니다.
ZK-SNARK는 복잡한 기술입니다. ZK-SNARK의 작동 방식에 대한 기본 아이디어는 단일 문서에서 명확하게 설명할 수 있지만 일부 계산을 확인하기 위해 실제로 ZK-SNARK를 구현하는 것은 계산 자체보다 몇 배 더 복잡합니다(따라서 이것이 ZK-SNARK의 증명이 EVM은 아직 개발 중이며 EVM에 대한 사기 증거는 이미 베타 버전입니다. ZK-SNARK 증명을 효율적으로 구현하려면 특수 목적의 최적화된 회로 설계, 생소한 프로그래밍 언어의 사용 및 기타 많은 문제가 수반됩니다. 반면 사기 증명은 그 자체로 간단합니다. 누군가 문제를 제기하면 온체인에서 직접 계산을 실행하기만 하면 됩니다. 효율성을 위해 이진 검색 체계가 추가되는 경우도 있지만 그렇게 해도 복잡성이 많이 추가되지는 않습니다.
ZK-SNARK는 복잡하지만 그 복잡성은 캡슐화된 복잡성입니다. 반면 사기 증명의 상대적으로 낮은 복잡성은 시스템 복잡성입니다. 다음은 사기 증명으로 도입된 시스템 복잡성의 일부 예입니다.
유효성 검사기의 딜레마를 피하기 위해 신중한 인센티브 엔지니어링이 필요합니다.
합의가 이루어지면 사기 증명을 위한 추가 트랜잭션 유형이 필요하며 동시에 많은 참가자가 동시에 사기 증명을 제출하기 위해 경쟁하는 경우 발생할 수 있는 상황을 고려합니다.
그들은 동기화 네트워크에 의존합니다.
검열 공격을 절도에 사용할 수도 있습니다.
사기 방지 기반 롤업은 유동성 공급자가 즉각적인 인출을 지원해야 합니다.
보조 제목
다양한 예
PoW(나카모토 컨센서스):메커니즘이 매우 간단하고 이해하기 쉽기 때문에 캡슐화 복잡성이 낮지만 시스템 복잡성(예: 이기적인 마이닝 공격)이 높습니다.
해시 함수:패키징 복잡성이 높지만 속성이 매우 잘 이해되어 시스템 복잡성이 낮습니다.
무작위 섞기 알고리즘:셔플 알고리즘은 내부적으로 복잡할 수 있지만(예: Whisk) 강한 임의성을 보장하고 이해하기 쉬울 수 있습니다.
채굴자 추출 가치(MEV):복잡한 트랜잭션을 지원하기에 충분히 강력한 프로토콜은 내부적으로는 상당히 단순할 수 있지만 이러한 복잡한 트랜잭션은 매우 비정상적인 방식으로 블록을 제안함으로써 프로토콜의 인센티브에 복잡한 시스템적 영향을 미칠 수 있습니다.
버클 트리:보조 제목
우리는 그것을 어떻게 평가합니까?
일반적으로 패키징 복잡성이 낮은 옵션은 시스템 복잡성이 낮은 옵션이기도 하므로 분명히 더 간단한 옵션이 하나 있습니다. 그러나 다른 때에는 하나의 복잡성과 다른 것 사이에서 어려운 선택을 해야 합니다. 복잡성을 캡슐화하는 경우 덜 위험하다는 것이 이 시점에서 분명해야 합니다. 시스템의 복잡성으로 인해 발생하는 위험은 사양 길이의 단순한 함수가 아닙니다. 블랙박스 .
그러나 복잡성의 캡슐화를 선호하는 이 접근 방식에는 한계가 있습니다. 소프트웨어 버그는 모든 코드에 나타날 수 있으며 코드가 점점 커질수록 오류 확률은 1에 가깝습니다. 때로는 캡슐화 복잡성으로 시작된 것이 새롭고 예상치 못한 방식으로 하위 시스템과 상호 작용해야 할 때 시스템 복잡성이 될 수 있습니다.
후자의 예로는 이더리움의 현재 2단계 상태 트리가 있습니다. 이 트리에는 계정 개체 트리가 있으며 각 계정 개체에는 자체 스토리지 트리가 있습니다.
이 트리 구조는 복잡하지만 처음에는 이 복잡성이 잘 캡슐화되어 있는 것처럼 보입니다. 나머지 프로토콜은 읽고 쓸 수 있는 키/값 저장소로서 트리와 상호 작용하므로 트리가 구성되는 방식에 대해 걱정할 필요가 없습니다. .
그러나 나중에 이 복잡성은 시스템적인 영향을 미치는 것으로 입증되었습니다. 계정이 임의로 큰 스토리지 트리를 가질 수 있는 기능은 특정 상태 부분(예: "0x1234로 시작하는 모든 계정")이 예측 가능한 크기를 가질 것으로 안정적으로 기대할 수 있는 방법이 없음을 의미했습니다. . 이로 인해 상태를 여러 부분으로 분할하기가 더 어려워지고 동기화 프로토콜의 설계와 스토리지 프로세스 분산 시도가 복잡해집니다.패키징 복잡성이 체계화되는 이유는 무엇입니까? 인터페이스가 변경되었기 때문입니다.해결 방법이 무엇입니까? Verkle 트리로 이동하려는 현재 제안에는 균형 잡힌 단일 레벨 트리 설계로의 이동도 포함됩니다.
궁극적으로 주어진 상황에서 어떤 유형의 복잡성이 선호되는지는 쉬운 답이 없는 질문입니다.우리가 할 수 있는 최선은 캡슐화 복잡성을 적당히, 그러나 너무 많이 지원하지 않고 각각의 구체적인 경우에 판단을 내리는 것입니다. 가지다때때로 패키징 복잡성을 크게 줄이기 위해 약간의 시스템 복잡성을 희생하는 것이 실제로 모범 사례입니다. 다른 경우에는 캡슐화된 것과 그렇지 않은 것을 잘못 판단할 수도 있습니다. 상황마다 다릅니다.
