원제: 이더리움 프로토콜의 가능한 미래, 6부: 과시(The Splurge)
원저자: @VitalikButerin
원곡: zhouzhou, BlockBeats
다음은 원본 내용입니다(원본 내용은 읽기 쉽고 이해하기 쉽도록 편집되었습니다).
어떤 것들은 단일 범주에 맞추기 어렵고, Ethereum 프로토콜의 설계에는 Ethereum의 성공에 매우 중요한 작은 세부 사항이 많이 있습니다. 실제로 콘텐츠의 약 절반은 다양한 유형의 EVM 개선을 다루고 나머지는 번영의 핵심인 다양한 틈새 주제로 구성되어 있습니다.
로드맵 2023: 번영
번영: 핵심 목표
EVM을 고성능의 안정적인 최종 상태로 전환
프로토콜에 계정 추상화를 도입하여 모든 사용자가 보다 안전하고 편리한 계정을 즐길 수 있도록 합니다.
거래 수수료 경제성을 최적화하고 확장성을 높이는 동시에 위험을 줄입니다.
장기적으로 이더리움을 크게 개선하기 위한 고급 암호화를 살펴보세요.
이 장의 내용
EVM 개선
어떤 문제가 해결되었나요?
현재 EVM은 정적으로 분석하기 어렵기 때문에 효율적인 구현을 생성하고 코드를 공식적으로 검증하며 추가 확장을 수행하기가 어렵습니다. 또한 EVM은 사전 컴파일을 통해 명시적으로 지원되지 않는 한 다양한 형태의 고급 암호화를 구현하기가 비효율적이고 어렵습니다.
그것은 무엇이며 어떻게 작동합니까?
현재 EVM 개선 로드맵의 첫 번째 단계는 다음 하드포크에 포함될 예정인 EVM Object Format(EOF)입니다. EOF는 다음과 같은 고유한 특성을 지닌 새로운 EVM 코드 버전을 지정하는 일련의 EIP입니다.
코드(실행 가능하지만 EVM에서 읽을 수 없음)와 데이터(읽을 수 있지만 실행할 수 없음) 간의 분리
동적 점프는 금지되며 정적 점프만 허용됩니다.
EVM 코드는 더 이상 연료 관련 정보를 관찰할 수 없습니다.
새로운 명시적 서브루틴 메커니즘이 추가되었습니다.
EOF 코드의 구조
호황: EVM 개선(계속)
레거시 계약은 계속 존재하고 생성될 수 있지만 결국에는 단계적으로 폐지될 수 있습니다(EOF 코드로 강제될 수도 있음). 새로운 스타일의 계약은 EOF로 인한 효율성 향상의 이점을 누릴 수 있습니다. 처음에는 서브루틴 기능을 통해 약간 더 작은 바이트코드를 통해, 나중에는 EOF 관련 새로운 기능 또는 가스 비용 절감을 통해 이점을 얻을 수 있습니다.
EOF 도입 이후 추가 업그레이드가 더욱 쉬워졌습니다. 현재 가장 많이 개발된 것은 EVM 모듈 연산 확장(EVM-MAX) 입니다. EVM-MAX는 특히 모듈러 연산을 위한 새로운 연산 세트를 생성하고 이를 다른 opcode를 통해 액세스할 수 없는 새로운 메모리 공간에 배치하여 몽고메리 곱셈 과 같은 최적화를 사용할 수 있도록 합니다.
새로운 아이디어는 EVM-MAX를 SIMD(Single Instruction Multiple Data) 기능과 결합하는 것입니다. SIMD는 오랫동안 이더리움에서 아이디어였으며 Greg Colvin의 EIP-616 에 의해 처음 제안되었습니다. SIMD는 해시 함수, 32비트 STARK, 격자 기반 암호화를 비롯한 다양한 형태의 암호화를 가속화하는 데 사용할 수 있으며, EVM-MAX와 SIMD의 결합으로 이러한 두 가지 성능 지향 확장이 자연스럽게 결합됩니다.
결합된 EIP의 대략적인 설계는 EIP-6690으로 시작하여 다음과 같습니다.
(i) 홀수 또는 (ii) 최대 2768까지 2의 거듭제곱을 모듈러스로 허용합니다.
각 EVM-MAX opcode(덧셈, 뺄셈, 곱셈)에 대해 3개의 즉치 x, y, z 대신 7개의 즉치(x_start, x_skip, y_start, y_skip , z_start, z_skip, count)를 사용하는 버전을 추가합니다. Python 코드에서 이러한 opcode는 다음과 같이 작동합니다.
범위(개수)에 있는 i의 경우:
mem[z_start + z_skip * 개수] = op(
mem[x_start + x_skip * 개수],
mem[y_start + y_skip * 개수]
)
실제 구현에서는 이 작업이 병렬로 처리됩니다.
최소한 2 모듈로의 거듭제곱에 대해 XOR, AND, OR, NOT 및 SHIFT(순환 및 비순환 모두)를 추가할 수 있습니다. 또한 타원 곡선 암호화, 소규모 도메인 암호화(예: Poseidon, Circle STARK), 기존 해시 함수(예: SHA 256, KECCAK, BLAKE)를 구현하기에 충분히 강력한 ISZERO(EVM 메인 스택에 출력 푸시)를 추가하고 격자 기반 암호화. 다른 EVM 업그레이드도 가능하지만 지금까지 관심을 덜 받았습니다.
기존 연구에 대한 링크
EOF: https://evmobjectformat.org/
EVM-MAX: https://eips.ethereum.org/EIPS/eip-6690
SIMD: https://eips.ethereum.org/EIPS/eip-616
남은 작업과 트레이드오프
현재 EOF는 다음 하드포크에 포함될 예정입니다. 마지막 순간에 이를 제거하는 것은 항상 가능하지만 이전 하드 포크에서는 기능이 일시적으로 제거되었으므로 그렇게 하는 것은 상당히 어려울 것입니다. EOF를 제거한다는 것은 향후 EVM에 대한 모든 업그레이드가 EOF 없이 수행되어야 함을 의미합니다. 이는 수행할 수 있지만 더 어려울 수 있습니다.
EVM의 주요 트레이드 오프는 L1 복잡성과 인프라 복잡성입니다. EOF는 EVM 구현에 추가해야 하는 코드의 양이 많고 정적 코드 검사도 상대적으로 복잡합니다. 그러나 그 대가로 우리는 단순화된 고급 언어, 단순화된 EVM 구현 및 기타 이점을 얻습니다. Ethereum L1의 지속적인 개선을 우선시하는 로드맵에는 EOF가 포함되고 구축되어야 한다고 할 수 있습니다.
수행해야 할 중요한 작업은 EVM-MAX 및 SIMD와 유사한 기능을 구현하고 다양한 암호화 작업의 가스 소비를 벤치마킹하는 것입니다.
로드맵의 다른 부분과 어떻게 상호 작용합니까?
L1은 L2가 더 쉽게 조정할 수 있도록 EVM을 조정합니다. 두 가지가 동시에 조정되지 않으면 호환성이 저하되고 부작용이 발생할 수 있습니다. 또한 EVM-MAX 및 SIMD는 많은 증명 시스템의 가스 비용을 줄여 L2를 더욱 효율적으로 만들 수 있습니다. 또한 효율성에 큰 영향을 주지 않고 동일한 작업을 수행할 수 있는 EVM 코드로 더 많은 사전 컴파일을 더 쉽게 대체할 수 있습니다.
계정 추상화
어떤 문제가 해결되었나요?
현재 거래는 ECDSA 서명이라는 한 가지 방법으로만 확인할 수 있습니다. 처음에 계정 추상화는 이를 뛰어넘어 계정의 확인 로직이 임의의 EVM 코드가 될 수 있도록 의도되었습니다. 이를 통해 다음과 같은 다양한 애플리케이션이 가능해졌습니다.
양자 저항 암호화로 전환
이전 키 교체( 권장되는 보안 관행으로 널리 간주됨 )
다중 서명 지갑과 사회 회복 지갑
낮은 가치 작업에는 하나의 키를 사용하고 높은 가치 작업에는 다른 키(또는 키 세트)를 사용합니다.
개인 정보 보호 프로토콜이 릴레이 없이 작동할 수 있도록 하여 복잡성을 크게 줄이고 주요 중앙 종속 지점을 제거합니다.
2015년에 계정 추상화가 제안된 이후 목표도 다수의 편의 목표를 포함하도록 확장되었습니다. 예를 들어 ETH는 없지만 일부 ERC 20이 있는 계정은 ERC 20으로 가스 비용을 지불할 수 있습니다. 다음은 이러한 목표에 대한 요약 차트입니다.
MPC(Multi-Party Computation)는 키 부분을 직접 결합하지 않고도 암호화 기술을 사용하여 서명을 생성하는 방식으로 키를 여러 부분으로 분할하고 여러 장치에 저장하는 데 사용되는 40년 된 기술 입니다.
EIP-7702 는 다음 하드포크에 도입될 예정인 제안으로, EIP-7702는 EOA 사용자를 포함한 모든 사용자에게 혜택을 주기 위해 계정 추상화 편의성 제공에 대한 인식이 높아진 결과이며, 단기적으로 모든 사용자의 향상을 목표로 한다. 경험하고 두 개의 생태계로 분할되는 것을 방지하세요.
작업은 EIP-3074 로 시작되어 결국 EIP-7702로 이어졌습니다. EIP-7702는 오늘날의 EOA(외부 소유 계정, 즉 ECDSA 서명으로 제어되는 계정)를 포함하여 모든 사용자에게 계정 추상화의 편의 기능을 제공합니다.
차트에서 볼 수 있듯이 일부 문제(특히 편의성 문제)는 다자간 계산이나 EIP-7702와 같은 증분 기술로 해결할 수 있지만 원래 계정 추상화 제안의 주요 보안 목표는 해결만 가능합니다. 원래 문제를 역추적하고 해결하여 달성하려면: 스마트 계약 코드가 거래 확인을 제어하도록 허용합니다. 지금까지 이것이 가능하지 않은 이유는 이를 안전하게 구현하는 것이 어렵기 때문입니다.
그것은 무엇이며 어떻게 작동합니까?
계정 추상화의 핵심은 간단합니다. 스마트 계약이 EOA뿐만 아니라 트랜잭션을 시작하도록 허용하는 것입니다. 전체적인 복잡성은 분산형 네트워크를 유지하고 서비스 거부 공격으로부터 보호하는 데 친화적인 방식으로 이를 구현하는 데서 비롯됩니다.
일반적인 주요 과제는 다중 실패 문제입니다.
확인 기능이 모두 단일 값 S에 의존하는 1,000개의 계정이 있고 현재 값 S가 mempool의 모든 트랜잭션을 유효하게 만드는 경우 S 값을 뒤집는 단일 트랜잭션으로 인해 mempool의 다른 모든 트랜잭션이 유효하지 않게 될 수 있습니다. . 이를 통해 공격자는 매우 저렴한 비용으로 트랜잭션을 mempool에 스팸으로 보내 네트워크 노드의 리소스를 차단할 수 있습니다.
DoS(서비스 거부) 위험을 제한하면서 기능을 확장하기 위한 수년간의 노력 끝에 이상적인 계정 추상화를 달성하기 위한 솔루션이 마침내 ERC-4337에 도달했습니다.
ERC-4337은 사용자 작업 처리를 검증과 실행의 두 단계로 나누어 작동합니다. 모든 유효성 검사가 먼저 처리되고 모든 실행은 나중에 처리됩니다. mempool에서는 유효성 검사 단계에 자신의 계정만 포함되고 환경 변수를 읽지 않는 경우에만 사용자 작업이 허용됩니다. 이는 다중 무효화 공격을 방지합니다. 또한 검증 단계에서는 엄격한 가스 제한이 적용됩니다.
ERC-4337은 당시 이더리움 클라이언트 개발자가 병합에만 집중하고 다른 기능을 처리할 추가 에너지가 없었기 때문에 추가 프로토콜 표준(ERC)으로 설계되었습니다. 이것이 ERC-4337이 일반 트랜잭션 대신 User Action이라는 개체를 사용하는 이유입니다. 그러나 최근 우리는 이 중 적어도 일부를 프로토콜에 작성해야 한다는 것을 깨달았습니다.
두 가지 주요 이유는 다음과 같습니다.
1. 계약으로서 EntryPoint의 본질적인 비효율성: 번들당 약 100,000가스의 고정 오버헤드와 사용자 작업당 수천 개의 추가 가스.
2. 이더리움 속성 보장의 필요성: 포함 목록에 의해 생성된 포함 보증은 계정 추상 사용자에게 이전되어야 합니다.
또한 ERC-4337은 두 가지 기능을 확장합니다.
Paymasters: 한 계정이 다른 계정을 대신하여 수수료를 지불할 수 있도록 하는 기능입니다. 이는 확인 단계에서 보낸 사람 계정 자체에만 액세스할 수 있다는 규칙을 위반하므로 지불 마스터 메커니즘의 보안을 보장하기 위해 특별한 처리가 도입됩니다.
집계자: BLS 집계 또는 SNARK 기반 집계와 같은 서명 집계 기능을 지원합니다. 이는 롤업에서 최대 데이터 효율성을 달성하는 데 필요합니다.
기존 연구에 대한 링크
계정의 추상적 역사에 대한 강의: https://www.youtube.com/watch?v=iLf8qpOmxQc
ERC-4337: https://eips.ethereum.org/EIPS/eip-4337
EIP-7702: https://eips.ethereum.org/EIPS/eip-7702
BLSWallet 코드(집계 기능 사용): https://github.com/getwax/bls-wallet
EIP-7562(프로토콜에 작성된 계정 추상화): https://eips.ethereum.org/EIPS/eip-7562
EIP-7701(EOF 기반 쓰기 프로토콜 계정 추상화): https://eips.ethereum.org/EIPS/eip-7701
남은 작업과 트레이드오프
현재 해결해야 할 가장 중요한 것은 계정 추상화를 프로토콜에 완전히 도입하는 방법입니다. 최근 프로토콜에 작성된 계정 추상화 EIP는 EIP-7701 입니다. 계정에는 확인을 위해 별도의 코드 섹션이 있을 수 있으며, 계정에 해당 코드 섹션이 설정된 경우 해당 계정의 거래 확인 단계에서 코드가 실행됩니다.
이 접근 방식의 흥미로운 점은 로컬 계정 추상화에 대한 두 가지 동등한 관점을 명확하게 보여 준다는 것입니다.
1. EIP-4337을 프로토콜의 일부로 만듭니다.
2. 서명 알고리즘이 EVM 코드 실행인 새로운 유형의 EOA
검증 중에 실행 코드의 복잡성에 대한 엄격한 경계를 설정하는 것부터 시작한다면(외부 상태에 대한 액세스는 허용되지 않으며 초기에 설정된 가스 제한도 너무 낮아 양자 저항 또는 개인 정보 보호 애플리케이션에 효과적이지 않음) 이 접근 방식은 다음과 같습니다. 보안은 매우 명확합니다. ECDSA 검증을 비슷한 시간이 걸리는 EVM 코드 실행으로 대체하면 됩니다.
그러나 시간이 지나면서 이러한 경계를 완화해야 합니다. 개인 정보 보호 애플리케이션이 릴레이 없이 작동하도록 허용하고 양자 저항성을 갖는 것이 모두 중요하기 때문입니다. 이를 위해서는 최소한의 검증 단계 없이 서비스 거부(DoS) 위험을 해결하는 보다 유연한 방법을 찾아야 합니다.
주요 절충점은 더 적은 수의 사람들을 만족시키는 솔루션을 신속하게 작성하는 것과 더 오래 기다리면 잠재적으로 더 이상적인 솔루션을 얻는 것인 것 같습니다. 이상적인 접근 방식은 아마도 일종의 하이브리드 접근 방식일 것입니다. 하이브리드 접근 방식은 일부 사용 사례를 더 빠르게 작성하고 다른 사용 사례를 탐색하는 데 더 많은 시간을 확보하는 것입니다. 또 다른 접근 방식은 L2에 먼저 계정 추상화의 보다 야심찬 버전을 배포하는 것입니다. 그러나 이에 대한 과제는 L2 팀이 제안을 구현하기 전에 특히 L1 및/또는 다른 L2가 향후 호환 가능한 접근 방식을 채택할 수 있도록 보장하기 전에 제안 채택 작업에 대해 확신을 가져야 한다는 것입니다.
명시적으로 고려해야 할 또 다른 애플리케이션은 L1 또는 전용 L2에 계정 관련 상태를 저장하지만 L1 및 호환되는 모든 L2에서 사용할 수 있는 키 스토리지 계정 입니다. 이를 효율적으로 수행하려면 L2가 L1S LOAD 또는 REMOTESTATICCALL 과 같은 opcode를 지원해야 할 수도 있지만, L2의 계정 추상화 구현도 이러한 작업을 지원해야 합니다.
로드맵의 다른 부분과 어떻게 상호 작용합니까?
포함된 목록은 계정 추상 트랜잭션을 지원해야 하며 실제로 포함된 목록의 요구 사항은 포함된 목록에 대한 유연성이 약간 더 있지만 실제로 분산형 멤풀의 요구 사항과 매우 유사합니다. 또한 가능할 때마다 L1과 L2 간에 계정 추상화 구현을 조정해야 합니다. 미래에 대부분의 사용자가 키 저장소 롤업을 사용할 것으로 예상된다면 계정 추상화 설계는 이를 기반으로 해야 합니다.
EIP-1559 개선
어떤 문제가 해결되나요?
EIP-1559는 2021년 이더리움에서 활성화되어 평균 블록 포함 시간을 크게 향상시켰습니다.
대기시간
그러나 현재 EIP-1559 구현은 여러 측면에서 불완전합니다.
1. 공식에는 약간의 결함이 있습니다. 분산에 따라 블록의 50%가 아니라 전체 블록의 약 50-53%를 대상으로 합니다(이는 수학자들이 산술-기하 평균 불평등이라고 부르는 것과 일치하지 않습니다. 관련된).
2. 극단적인 상황에서는 충분히 빨리 적응하지 못합니다.
블롭에 대한 최신 공식(EIP-4844)은 첫 번째 문제를 해결하기 위해 특별히 설계되었으며 전반적으로 더 간단합니다. 그러나 EIP-1559 자체나 EIP-4844는 두 번째 문제를 해결하려고 시도하지 않습니다. 따라서 현 상태는 두 가지 서로 다른 메커니즘을 포함하는 지저분한 중간 상태이며, 시간이 지남에 따라 둘 다 개선되어야 한다는 주장이 있습니다.
또한 EIP-1559와 관련이 없지만 EIP-1559 조정을 통해 해결할 수 있는 이더리움 리소스 가격 책정에는 다른 약점이 있습니다. 주요 문제 중 하나는 평균 시나리오와 최악 시나리오의 차이입니다. 이더리움의 리소스 가격은 블록의 전체 가스 소비가 리소스를 차지하지만 실제 평균 사용량은 최악의 시나리오를 처리하도록 설정되어야 합니다. 이보다 훨씬 낮으므로 비효율성이 발생합니다.
다차원 가스란 무엇이며 어떻게 작동합니까?
이러한 비효율성에 대한 해결책은 다차원적인 가스 입니다. 즉, 다양한 자원에 대해 서로 다른 가격과 제한을 설정하는 것입니다. 이 개념은 기술적으로 EIP-1559와 독립적이지만 EIP-1559가 있으면 이 솔루션을 더 쉽게 구현할 수 있습니다. EIP-1559가 없으면 여러 리소스 제약이 포함된 블록을 최적으로 패키징하는 것은 복잡한 다차원 배낭 문제 가 될 것입니다. EIP-1559를 사용하면 대부분의 블록은 어떤 리소스에서도 전체 용량에 도달하지 않으므로 충분한 수수료를 지불하는 모든 거래 수락과 같은 간단한 알고리즘이면 충분합니다.
현재 실행 및 데이터 블록을 위한 다차원 가스가 있으며 원칙적으로 이를 호출 데이터(트랜잭션 데이터), 상태 읽기/쓰기 및 상태 크기 확장과 같은 더 많은 차원으로 확장할 수 있습니다.
EIP-7706은 특히 통화 데이터를 위한 새로운 가스 차원을 도입합니다. 동시에 세 가지 유형의 가스를 (EIP-4844 스타일) 프레임워크로 통합하여 다차원 가스 메커니즘을 단순화하여 EIP-1559의 수학적 결함도 해결합니다. EIP-7623 은 완전히 새로운 차원을 도입하지 않고도 평균 및 최악의 리소스 문제에 대한 최대 통화 데이터를 보다 엄격하게 제한하는 보다 정확한 솔루션입니다.
추가 연구 방향은 EIP-4844 메커니즘에 의해 도입된 주요 불변성을 유지하면서 업데이트 속도 문제를 해결하고 더 빠른 기본 요금 계산 알고리즘을 찾는 것입니다(예: 장기적으로 평균 사용량이 목표 값에 거의 근접함). ).
기존 연구에 대한 링크
EIP-1559 FAQ: EIP-1559 FAQ
EIP-1559에 대한 실증적 분석: 실증적 분석
빠른 조정이 가능한 개선 제안: 개선 제안
EIP-4844 FAQ의 기본 수수료 메커니즘에 관한 부분: EIP-4844 FAQ
EIP-7706: EIP-7706
EIP-7623: EIP-7623
다차원 가스: 다차원 가스
남은 노력과 절충점은 무엇입니까?
다차원 가스에는 두 가지 주요 절충점이 있습니다.
1. 프로토콜 복잡성 증가: 다차원 가스의 도입으로 인해 프로토콜이 더욱 복잡해집니다.
2. 블록을 채우는 데 필요한 최적 알고리즘의 복잡성 증가: 블록을 최대 용량으로 가져오는 데 필요한 최적의 알고리즘도 복잡해집니다.
호출 데이터의 경우 프로토콜 복잡성이 상대적으로 작지만 EVM 내부의 가스 크기(예: 저장소 읽기 및 쓰기)의 경우 증가합니다. 문제는 사용자가 가스 한도를 설정할 뿐만 아니라 계약도 다른 계약을 호출할 때 한도를 설정한다는 것입니다. 그리고 현재 그들이 한계를 설정할 수 있는 유일한 방법은 1차원적입니다.
간단한 해결책은 다차원 가스를 EOF 내부에서만 사용할 수 있도록 만드는 것입니다. EOF에서는 계약이 다른 계약을 호출할 때 가스 제한을 설정하는 것을 허용하지 않기 때문입니다. Non-EOF 계약은 저장 작업을 수행할 때 모든 유형의 가스에 대한 수수료를 지불해야 합니다(예를 들어 SLOAD가 블록 저장소 액세스 가스 한도의 0.03%를 차지하는 경우 비EOF 사용자에게도 실행 가스의 0.03%가 부과됩니다) 수수료 한도).
다차원 가스에 대한 더 많은 연구는 이러한 상충관계를 이해하고 이상적인 균형을 찾는 데 도움이 될 것입니다.
로드맵의 다른 부분과 어떻게 상호 작용합니까?
다차원 가스를 성공적으로 구현하면 특정 최악의 경우 리소스 사용량을 크게 줄일 수 있으므로 STARKed 해시 기반 바이너리 트리와 같은 요구 사항을 지원하기 위해 성능을 최적화해야 하는 부담이 줄어듭니다. 상태 규모 증가에 대한 명확한 목표를 설정하면 클라이언트 개발자가 향후 요구 사항을 더 쉽게 계획하고 예측할 수 있습니다.
앞서 언급했듯이 EOF가 있으면 가스의 관찰할 수 없는 특성으로 인해 다차원 가스의 더 극단적인 버전을 구현하기가 더 쉬워집니다.
검증 가능한 지연 함수(VDF)
어떤 문제가 해결되나요?
현재 이더리움은 RANDAO를 기반으로 한 무작위성을 사용하여 제안자를 선택합니다. 이는 각 제안자가 미리 약속한 비밀을 공개하도록 요구하고 공개된 각 비밀을 무작위성에 혼합하는 방식으로 작동합니다.
따라서 각 제안자는 1개의 제어를 갖습니다. 즉, 나타나지 않음으로써 무작위성을 변경할 수 있습니다(비용 발생). 하나의 기회를 포기하고 두 개의 새로운 기회를 얻는 경우는 매우 드물기 때문에 이 접근 방식은 제안자를 찾는 데 적합합니다. 그러나 이는 임의성을 요구하는 온체인 애플리케이션에는 적합하지 않습니다. 이상적으로는 보다 강력한 임의성 소스를 찾아야 합니다.
VDF란 무엇이며 어떻게 작동하나요?
검증 가능한 지연 함수는 순차적으로만 평가할 수 있고 병렬화를 통해 가속할 수 없는 함수입니다. 간단한 예는 반복되는 해싱입니다: for i in range( 10** 9): x = hash(x). SNARK를 사용하여 정확하다고 입증된 출력 결과는 임의의 값으로 사용될 수 있습니다.
아이디어는 입력이 시간 T에서 사용 가능한 정보를 기반으로 선택되는 반면 출력은 시간 T에서 아직 알려지지 않았다는 것입니다. 출력은 누군가가 완전히 계산을 실행한 후 T 이후 특정 시간에만 사용할 수 있습니다. 누구나 계산을 실행할 수 있으므로 결과를 보류할 가능성이 없고 결과를 조작할 수도 없습니다.
검증 가능한 지연 기능의 주요 위험은 우발적인 최적화입니다. 누군가가 예상보다 빠르게 기능을 실행하여 시간 T에 공개되는 정보를 조작하게 됩니다.
예기치 않은 최적화는 두 가지 방법으로 발생할 수 있습니다.
1. 하드웨어 가속: 누군가 기존 하드웨어보다 더 빠르게 계산 루프를 실행할 수 있는 ASIC을 구축합니다.
2. 우연한 병렬화: 누군가는 100배의 리소스가 필요함에도 불구하고 함수를 병렬화하여 더 빠르게 실행하는 방법을 찾습니다.
성공적인 VDF를 만드는 작업은 효율성과 실용성을 유지하면서 두 가지 문제를 모두 피하는 것입니다(예를 들어 해시 기반 접근 방식의 한 가지 문제는 실시간으로 해시를 교정하는 SNARK에 무거운 하드웨어가 필요하다는 것입니다). 하드웨어 가속은 공익 행위자가 거의 최적에 가까운 VDF ASIC을 자체적으로 생성 및 배포하는 방식으로 해결되는 경우가 많습니다.
기존 연구에 대한 링크
VDF 연구 웹사이트: vdfresearch.org
이더리움의 VDF 공격에 대한 생각, 2018: 공격에 대한 생각
제안된 VDF MinRoot에 대한 공격: MinRoot에 대한 공격
남은 노력과 절충점은 무엇입니까?
현재 모든 측면에서 Ethereum 연구원의 요구 사항을 완전히 충족하는 VDF 구성은 없습니다. 그러한 기능을 찾으려면 여전히 더 많은 작업이 필요합니다. 발견된 경우 주요 절충점은 이를 포함할지 여부입니다. 기능과 프로토콜 복잡성 및 보안 위험 간의 간단한 절충점입니다.
VDF가 안전하다고 생각했지만 구현 방법에 따라 안전하지 않은 것으로 판명되면 보안은 RANDAO 가정(공격자당 1비트 제어)으로 저하되거나 약간 더 나빠집니다. 따라서 VDF가 실패하더라도 프로토콜은 중단되지 않지만 VDF에 크게 의존하는 응용 프로그램이나 새로운 프로토콜 기능은 중단됩니다.
로드맵의 다른 부분과 어떻게 상호 작용합니까?
VDF는 제안자 선택에 보안을 추가하는 것 외에도 (i) 무작위성에 의존하는 온체인 애플리케이션 및 (ii) 비록 VDF 제작을 기반으로 하지만 암호화 메모리 풀에 애플리케이션이 있는 이더리움 프로토콜의 상대적으로 독립적인 구성 요소입니다. 암호화된 메모리 풀은 아직 발생하지 않은 추가 암호화 발견에 여전히 의존합니다.
기억해야 할 한 가지 중요한 점은 하드웨어 불확실성을 고려할 때 VDF 출력 생성과 필요성 사이에 약간의 마진이 있다는 것입니다. 이는 해당 정보가 몇 블록 전에 공개될 것임을 의미합니다. 이는 수용 가능한 비용일 수 있지만 단일 탱크를 최종 결정하거나 설계를 선택하는 위원회에서 고려해야 합니다.
난독화 및 일회성 서명: 암호화의 먼 미래
어떤 문제가 해결되나요?
Nick Szabo의 가장 유명한 기사 중 하나는 The God Agreement에 관한 1997년 논문입니다. 논문에서 그는 많은 다자간 애플리케이션이 상호 작용을 관리하기 위해 신뢰할 수 있는 제3자에 의존하고 있음을 지적했습니다. 그의 견해에 따르면 암호화의 역할은 실제로 특정 참가자에 대한 신뢰를 요구하지 않고 동일한 작업을 수행하는 신뢰할 수 있는 시뮬레이션된 제3자를 만드는 것입니다.
지금까지 우리는 이 이상을 부분적으로만 달성할 수 있었습니다. 우리에게 필요한 것은 데이터와 계산이 꺼지거나, 검열되거나, 변조될 수 없는 투명한 가상 컴퓨터이고 개인 정보 보호가 목표가 아니라면, 블록체인은 제한된 확장성에도 불구하고 이 목표를 달성할 수 있습니다.
개인 정보 보호가 목표라면 최근까지 특정 응용 프로그램을 위한 몇 가지 특정 프로토콜만 개발할 수 있었습니다. 기본 인증을 위한 디지털 서명, 원시 익명성을 위한 링 서명 및 연결 가능한 링 서명, ID 기반 암호화에 대한 특정 가정 하에서 보다 편리한 암호화 활성화 신뢰할 수 있는 발행자, 차임형 전자화폐에 대한 블라인드 서명 등 이 접근 방식을 사용하려면 새로운 애플리케이션마다 많은 작업이 필요합니다.
2010년대에 우리는 프로그래밍 가능한 암호화를 기반으로 하는 더욱 다양하고 강력한 접근 방식을 처음으로 엿볼 수 있었습니다. 모든 새로운 애플리케이션에 대해 새로운 프로토콜을 만드는 대신 강력한 새 프로토콜, 특히 ZK-SNARK를 사용하여 임의의 프로그램에 암호화 보장을 추가할 수 있습니다.
ZK-SNARK를 사용하면 사용자는 자신이 보유한 데이터에 대한 임의의 주장을 증명할 수 있으며, 증명은 (i) 확인하기 쉽고 (ii) 주장 자체 이외의 데이터는 공개하지 않습니다. 이는 개인 정보 보호와 확장성 측면에서 엄청난 개선이며, 저는 이를 인공 지능에 있어서 변환기의 영향에 비유합니다. 수천 명이 특정 직무에 지원하던 것이 예상치 못한 광범위한 문제를 처리할 수 있는 만능 솔루션으로 갑자기 대체되었습니다.
그러나 ZK-SNARK는 매우 강력한 세 가지 범용 프리미티브 중 첫 번째에 불과합니다. 이 프로토콜은 매우 강력해서 제가 어렸을 때 플레이했던 카드 게임이자 TV 쇼인 Yu-Gi-Oh의 매우 강력한 카드 세트인 이집트 신 카드가 생각납니다.
이집트 신 카드는 세 가지 매우 강력한 카드입니다. 전설에 따르면 이 카드를 만드는 과정은 치명적일 수 있으며 그 힘으로 인해 결투에서는 사용이 금지됩니다. 마찬가지로 암호화에는 세 가지 이집트 신 프로토콜 세트가 있습니다.
ZK-SNARK는 무엇이며 어떻게 작동하나요?
ZK-SNARK는 우리가 이미 보유하고 있는 더 높은 수준의 성숙도를 지닌 세 가지 프로토콜 중 하나입니다. 지난 5년 동안 증명자 속도와 개발자 친화성이 크게 향상되면서 ZK-SNARK는 이더리움의 확장성과 개인 정보 보호 전략의 초석이 되었습니다. 그러나 ZK-SNARK에는 중요한 제한 사항이 있습니다. 이를 증명하려면 데이터를 알아야 합니다. ZK-SNARK 애플리케이션의 각 상태에는 해당 상태에 대한 읽기 또는 쓰기를 승인하기 위해 존재해야 하는 고유한 소유자가 있어야 합니다.
이러한 제한이 없는 두 번째 프로토콜은 FHE(완전 동형 암호화)입니다. FHE를 사용하면 데이터를 보지 않고도 암호화된 데이터에 대해 모든 계산을 수행할 수 있습니다. 이를 통해 데이터와 알고리즘을 비공개로 유지하면서 사용자의 이익을 위해 사용자 데이터에 대한 계산을 수행할 수 있습니다.
또한 거의 완벽한 보안 및 개인정보 보호를 보장하기 위해 MACI와 같은 투표 시스템을 확장할 수도 있습니다. FHE는 오랫동안 실용적으로 사용하기에는 너무 비효율적이라고 여겨졌으나 이제는 마침내 실용적인 응용이 나타나기 시작할 만큼 효율적이 되었습니다.
Cursive는 개인 정보를 보호하면서 공통 관심사를 검색하기 위해 양 당사자 계산 및 FHE(완전 동형 암호화)를 활용하는 애플리케이션입니다.
그러나 FHE에는 한계가 있습니다. FHE를 기반으로 하는 모든 기술에는 여전히 누군가가 암호 해독 키를 보유해야 합니다. 이는 M-of-N 분산 설정일 수 있으며 TEE(신뢰할 수 있는 실행 환경)를 사용하여 두 번째 보호 계층을 추가할 수도 있지만 이는 여전히 제한 사항입니다.
다음은 처음 두 프로토콜의 조합보다 훨씬 더 강력한 세 번째 프로토콜인 구별 불가능 난독화입니다. 기술이 아직 성숙되지는 않았지만 2020년 현재 표준 보안 가정을 기반으로 이론적으로 유효한 프로토콜을 보유하고 있으며 최근 이를 구현하기 시작했습니다.
구별 불가능한 난독화를 사용하면 프로그램의 모든 내부 세부 정보를 숨기면서 임의의 계산을 수행하는 암호화된 프로그램을 만들 수 있습니다. 간단한 예로, 개인 키를 소수에 서명하는 데만 사용하고 이 프로그램을 다른 사람에게 배포할 수 있도록 허용하는 난독화된 프로그램에 개인 키를 넣을 수 있습니다. 이 프로그램을 사용하면 어떤 소수에도 서명할 수 있지만 키를 추출할 수는 없습니다. 그러나 그 기능은 그 이상입니다. 해시와 결합하면 다른 암호화 기본 요소 등을 구현하는 데 사용할 수 있습니다.
구별 불가능한 난독화 장치가 할 수 없는 유일한 일은 자신이 복사되는 것을 방지하는 것입니다. 그러나 양자 컴퓨터를 보유한 모든 사람에게 의존하는 기술인 양자 원샷 서명에 의존하는 더 강력한 기술이 기다리고 있습니다.
난독화와 일회성 서명을 결합함으로써 거의 완벽한 무신뢰 제3자를 구축할 수 있습니다. 암호화만으로는 달성할 수 없고 여전히 블록체인이 보장해야 하는 유일한 목표는 검열 저항입니다. 이러한 기술은 이더리움 자체를 더욱 안전하게 만들 뿐만 아니라 그 위에 더욱 강력한 애플리케이션을 구축할 수 있게 해줍니다.
이러한 기본 요소가 추가 기능을 추가하는 방법을 더 잘 이해하기 위해 투표를 주요 예로 사용합니다. 투표는 매우 강력한 검증 가능성 및 개인 정보 보호를 포함하여 여러 가지 복잡한 보안 속성을 충족해야 하기 때문에 흥미로운 문제입니다. 강력한 보안 속성을 갖춘 투표 프로토콜이 수십 년 동안 존재했지만, 우리는 이를 더욱 어렵게 만들 수 있으며 임의의 투표 프로토콜(예: 2차 투표, 쌍별 제한된 2차 자금 조달, 클러스터 일치 2차 자금 조달 등)을 처리할 수 있는 설계가 필요합니다. 즉, 우리는 계산 단계가 임의의 절차가 되기를 원합니다.
먼저, 투표 결과를 블록체인에 공개적으로 올려놓는다고 가정해 보겠습니다. 이는 우리에게 공개 검증 가능성(투표 집계 및 자격 규칙을 포함하여 최종 결과가 올바른지 누구나 확인할 수 있음)과 검열 저항(사람들이 투표하는 것을 막을 수 없음)을 제공합니다. 하지만 우리에게는 프라이버시가 없습니다.
다음으로 ZK-SNARK를 추가하여 이제 개인 정보 보호 기능을 갖게 되었습니다. 모든 투표는 익명으로 진행되며 승인된 유권자만 투표할 수 있고 각 유권자는 한 번만 투표할 수 있습니다.
다음으로 투표가 중앙 서버의 암호 해독 키로 암호화되는 MACI 메커니즘을 소개합니다. 중앙 서버는 중복 투표 제거, ZK-SNARK 증명 결과 발행 등 투표 집계 프로세스를 담당합니다. 이는 이전 보증을 유지하지만(서버가 부정 행위를 하더라도!) 서버가 정직하다면 강제 방지 보증도 추가합니다. 사용자는 원하더라도 자신이 투표한 방법을 증명할 수 없습니다. 이는 사용자가 자신의 투표를 증명할 수는 있지만 해당 투표를 상쇄하기 위해 투표하지 않았다는 것을 증명할 수 없기 때문입니다. 이를 통해 뇌물 수수 및 기타 공격을 방지할 수 있습니다.
FHE에서 투표 계산을 실행한 다음 N/2-of-N 임계값 암호 해독 계산을 수행합니다. 이는 강제 저항 보장을 1-of-1 대신 N/2-N으로 증가시킵니다.
우리는 투표 집계 프로그램을 난독화하고 승인된 경우에만 결과를 출력할 수 있도록 난독화 프로그램을 설계합니다. 인증 방법은 블록체인 합의 증명, 일종의 작업 증명 또는 이 둘의 조합일 수 있습니다. 이는 강제 방지 보장을 거의 완벽하게 만듭니다. 블록체인 합의의 경우 검증자의 51%가 작업 증명의 경우 균열을 위해 공모해야 하며, 모두가 공모하더라도 투표가 다시 계산됩니다. 개별 유권자를 추출하는 행위 역시 비용이 매우 많이 듭니다. 개별 유권자의 행동을 추출하는 어려움을 더욱 높이기 위해 프로그램이 최종 투표 수를 무작위로 약간 조정하도록 할 수도 있습니다.
특정 유형의 정보에 대해 서명을 한 번만 사용할 수 있도록 양자 컴퓨팅을 사용하는 기본 요소인 일회성 서명을 추가했습니다. 이는 반군 보장을 진정으로 완벽하게 만듭니다.
구별 불가능한 난독화는 다른 강력한 애플리케이션도 지원합니다. 예를 들어:
1. 분산형 자율 조직(DAO), 온체인 경매 및 임의의 내부 비밀 상태가 있는 기타 애플리케이션.
2. 진정한 보편적인 신뢰할 수 있는 설정: 누군가가 키를 포함하는 난독화된 프로그램을 만들고, 프로그램을 실행하고 출력을 제공하여 해시(키, 프로그램)를 프로그램에 입력으로 넣을 수 있습니다. 이러한 프로그램이 있으면 누구든지 프로그램 3을 자체에 넣고 프로그램의 미리 입력된 키를 자신의 키와 결합하여 설정을 확장할 수 있습니다. 이는 모든 프로토콜에 대해 1-of-N 신뢰할 수 있는 설정을 생성하는 데 사용할 수 있습니다.
3. ZK-SNARK 확인에는 서명만 필요합니다. 이를 구현하는 것은 매우 간단합니다. 신뢰할 수 있는 환경을 설정하고 유효한 ZK-SNARK가 있는 경우에만 키를 사용하여 메시지에 서명하는 난독화된 프로그램을 누군가 만들도록 합니다.
4. 암호화된 메모리 풀: 트랜잭션 암호화가 매우 간단해지기 때문에 향후 특정 온체인 이벤트가 발생할 때만 트랜잭션을 해독할 수 있습니다. 여기에는 성공적으로 실행되는 VDF(검증 가능한 지연 기능)도 포함될 수 있습니다.
일회성 서명을 사용하면 검열 공격은 여전히 가능하지만 최종 반전에 대한 51% 공격으로부터 블록체인을 면역할 수 있습니다. 일회성 서명과 같은 기본 요소는 양자 통화를 가능하게 하여 블록체인 없이 이중 지출 문제를 해결합니다. 하지만 더 많은 복잡한 애플리케이션에는 여전히 체인이 필요합니다.
이러한 기본 요소를 충분히 효율적으로 만들 수 있다면 전 세계 대부분의 애플리케이션을 분산화할 수 있습니다. 주요 병목 현상은 구현의 정확성을 확인하는 것입니다.
다음은 일부 기존 연구에 대한 링크입니다.
1. 구별 불가능 난독화 프로토콜(2021): 구별 불가능 난독화
2. 난독화가 이더리움에 어떻게 도움이 되는지: 난독화가 이더리움에 어떻게 도움이 되는지
3. 최초로 알려진 원샷 서명 구성: 최초로 알려진 원샷 서명 구성
4. 난독화 구현 시도(1): 난독화 구현 시도(1)
5. 난독화 구현 시도(2): 난독화 구현 시도(2)
앞으로 해야 할 일은 무엇이며, 그에 따른 절충점은 무엇입니까?
아직 해야 할 일이 많고, 구별할 수 없는 난독화는 아직 미성숙하며, 애플리케이션에 유용하기에는 후보 구성이 놀라울 정도로 느리게 실행됩니다(그 이상은 아니더라도). 구별할 수 없는 혼란은 이론적 다항식 시간이 걸리는 것으로 알려져 있지만 실제 적용에서는 우주의 수명보다 더 오래 지속될 수 있습니다. 최근 프로토콜은 런타임에서 약간의 개선을 보여주었지만 일상적인 사용에는 여전히 오버헤드가 너무 높습니다. 한 구현자는 런타임을 1년으로 추정합니다.
양자 컴퓨터는 아직 존재하지도 않습니다. 인터넷에서 볼 수 있는 모든 구성은 4비트 이상을 수행할 수 없는 프로토타입이거나 전혀 실질적인 양자 컴퓨터가 아닙니다. Shor의 알고리즘이나 Grover의 알고리즘과 같은 의미 있는 계산을 실행할 수 없습니다. 최근에는 진짜 양자 컴퓨터가 멀지 않다는 징후가 나타났습니다. 그러나 진짜 양자 컴퓨터가 곧 출시되더라도 랩톱이나 휴대폰에서 양자 컴퓨터를 사용하는 일반 사용자는 강력한 기관이 타원 곡선 암호화를 해독하기까지 수십 년을 기다려야 할 수 있습니다.
구별할 수 없는 난독화의 경우 주요 균형점은 보안 가정에 있으며 특별한 가정을 사용하는 보다 급진적인 설계가 있습니다. 이러한 디자인은 일반적으로 더 현실적인 런타임을 가지지만 때로는 특별한 가정이 깨지는 경우도 있습니다. 시간이 지남에 따라 우리는 격자를 더 잘 이해하게 되어 쉽게 깨지지 않는 가설을 공식화할 수 있습니다. 그러나 이 길은 더 위험하다. 보다 보수적인 접근 방식은 보안이 표준 가정으로 축소된 프로토콜을 고수하는 것입니다. 그러나 이는 충분히 빠르게 실행되는 프로토콜을 얻기까지 시간이 더 오래 걸릴 수 있음을 의미할 수 있습니다.
로드맵의 다른 부분과 어떻게 상호 작용합니까?
매우 강력한 암호화는 다음과 같이 게임에 혁명을 일으킬 수 있습니다.
1. 서명만큼 쉽게 확인할 수 있는 ZK-SNARK를 얻으면 더 이상 집계 프로토콜이 필요하지 않으며 온체인에서 직접 확인할 수 있습니다.
2. 일회성 서명은 보다 안전한 지분 증명 프로토콜을 의미할 수 있습니다.
3. 많은 복잡한 개인 정보 보호 프로토콜은 개인 정보를 보호하는 EVM(Ethereum Virtual Machine)으로만 대체하면 됩니다.
4. 암호화된 메모리 풀을 구현하기가 더 쉬워졌습니다.
Ethereum의 L1은 본질적으로 보안 가정에서 보수적이어야 하므로 처음에는 이점이 애플리케이션 계층에서 발생합니다. 그러나 ZK-SNARK의 출현과 마찬가지로 애플리케이션 계층만 사용하면 파괴적일 수 있습니다.
