a16z: zkVM으로 효율적인 보안을 위한 경로 탐색하기

저자: 저스틴 탈러 출처: a16z 번역: 굿오바, 골든파이낸스

제로 지식 가상 머신(zkVM)은 다음을 목표로 합니다. SNARK에 대한 전문 지식이 없는 사람들도 특정 입력(또는 목격)에 대해 프로그램을 올바르게 실행했음을 증명할 수 있도록 하는 "대중에게 SNARK를 제공하는 것"입니다. 핵심 강점은 개발자 경험이지만, 현재 zkVM은 보안과 성능 측면에서 여전히 상당한 도전에 직면해 있습니다. zkVM이 약속을 이행하려면 설계자는 이러한 장애물을 극복해야 합니다. 이 문서에서는 완료하는 데 수년이 걸릴 수 있는 프로세스인 zkVM 개발의 가능한 단계를 살펴봅니다. 곧 실현될 것이라는 누군가의 말을 믿지 마세요.

도전 과제

보안 측면에서 보면, zkVM은 매우 복잡한 소프트웨어 프로젝트이며 여전히 취약점으로 가득 차 있습니다.

성능 측면에서는 프로그램의 올바른 실행이 기본적으로 실행하는 것보다 수십만 배 느릴 수 있으므로 대부분의 앱의 실제 배포는 현재로서는 가능하지 않습니다. >.

그럼에도 불구하고 블록체인 업계에서는 zkVM이 이미 즉시 배포할 준비가 되어 있으며 일부 프로젝트에서는 이미 온체인 활동에 대한 영지식 증명을 생성하기 위해 높은 컴퓨팅 비용을 지불하고 있다고 선전하는 목소리가 계속되고 있습니다. 그러나 zkVM에는 여전히 많은 취약점이 존재하기 때문에, 이러한 접근 방식은 실제로는 시스템이 SNARK에 의해 보호되는 것처럼 보이게 하기 위한 비용이 많이 드는 위장에 불과하며, 실제로는 권한 제어에 의존하거나 더 나쁜 것은 SNARK에 노출되는 것입니다. -공격 위험에 노출.

진정으로 안전하고 효율적인 zkVM을 구축하기까지는 아직 몇 년이 더 필요한 것이 현실입니다. 이 백서에서는 zkVM의 실제 진행 상황을 추적하고, 과대광고를 줄이고, 커뮤니티의 관심을 실제 혁신에 집중할 수 있도록 일련의 특정적이고 단계적인 목표를 제안합니다.

보안 개발 단계

배경

SNARK 기반 zkVM은 일반적으로 두 가지 핵심 구성 요소를 포함합니다:

1. 다항식 대화형 오라클 증명( 다항식 대화형 오라클 증명, PIOP): 다항식(또는 다항식에서 파생된 제약 조건)을 증명하기 위한 대화형 증명 프레임워크입니다.

2. 다항식 커밋 체계(PCS): 증명자가 다항식 평가 결과를 발견되지 않고 위조할 수 없도록 보장합니다.

zkVM은 유효한 실행 궤적을 제약 조건 시스템으로 인코딩한 다음, 이러한 제약 조건의 만족을 증명하기 위해 다음과 같이 사용하여 VM의 레지스터 및 메모리의 올바른 사용을 보장합니다. SNARK를 사용하여 이러한 제약 조건의 만족을 증명합니다.

이러한 복잡한 시스템에서 zkVM이 취약하지 않도록 보장하는 유일한 방법은 공식 검증입니다. 다음은 zkVM 보안의 여러 단계로, 1단계는 프로토콜 정확성에 초점을 맞추고 2단계와 3단계는 구현 정확성에 중점을 둡니다.

보안 1단계: 올바른 프로토콜

2. PIOP의 신뢰성에 대한 공식 검증 증명;

3. 특정 암호화 가정 또는 이상적인 모델 하에서 PCS가 구속력이 있다는 공식 검증 증명;

4. 사용하는 경우 피아트-샤미르, PIOP와 PCS를 결합하여 얻은 간결한 인수는 확률적 예측 모델에서 안전한 공식 검증 증명입니다(필요에 따라 다른 암호화 가정으로 보강);

5. PIOP가 적용한 제약 시스템은 VM의 의미론과 동일합니다. 공식 검증 증명;

6. 이 모든 부분을 포괄적으로 '접착'하여 VM 바이트코드에 지정된 모든 프로그램을 실행하기 위한 공식적으로 검증된 안전한 단일 SNARK 증명으로 통합합니다. 프로토콜이 영지식 프로토콜을 의도하는 경우, 이 속성도 공식적으로 검증하여 증인에 대한 민감한 정보가 공개되지 않도록 해야 합니다.

zkVM이 재귀를 사용하는 경우, 재귀 중에 관련된 PIOP, 커밋 체계 및 제약 시스템을 확인해야 합니다. strong>, 그렇지 않으면 하위 단계가 완료된 것으로 간주할 수 없습니다.

보안 2단계: 올바른 유효성 검사기 구현

이 단계에서는 zkVM validator(예: Rust, Solid)의 실제 구현이 유효성을 검사해야 합니다. 구현(예: Rust, Solid 등)이 첫 번째 단계에서 검증한 프로토콜을 준수하는지 확인하기 위해 공식 검증을 수행해야 합니다. 이 단계를 완료한다는 것은 zkVM의 구현이 서류상의 보안 프로토콜이나 Lean과 같은 언어로 작성된 비효율적인 사양이 아니라 이론적 설계와 일치한다는 것을 의미합니다.

증명자가 아닌 검증자에게만 집중하는 것이 중요한 이유는 크게 두 가지입니다. 첫째, 검증자가 올바른지 확인하는 것은 zkVM 증명 시스템의 완전성을 보장합니다(즉, 검증자가 잘못된 증명을 수락하도록 속일 수 없도록 하는 것입니다). 잘못된 증명을 수락하도록 속일 수 없도록). 둘째, zkVM의 검증자 구현은 증명자 구현보다 훨씬 더 간단하며, 검증자의 정확성이 단기간에 보장될 가능성이 더 높습니다.

보안 3단계: 올바른 증명자 구현

이 단계에서는 zkVM의 실제 증명자 구현이 공식적으로 구현되어 있어야 합니다. 구현은 1단계와 2단계에서 검증한 증명 시스템에 대한 증명을 정확하게 생성할 수 있는지 확인하기 위해 공식적으로 검증된다. 이 단계의 목표는 완전성, 즉 zkVM을 사용하는 어떤 시스템도 법적 진술을 증명할 수 없기 때문에 고착화되지 않도록 하는 것입니다. zkVM이 영지식 속성을 가져야 하는 경우, 증명이 증인에 대한 정보를 노출하지 않도록 공식적인 검증을 제공해야 합니다.

예상 타임라인

1단계 진행 상황: 내년에 약간의 진전을 기대할 수 있습니다(예: ZKLib가 그러한 노력 중 하나입니다). 그러나 최소 2년 동안은 1단계의 요구사항을 완벽하게 충족하는 zkVM은 없을 것입니다.

2단계 및 3단계: 이 단계는 1단계의 일부 측면과 병행하여 진행할 수 있습니다. 예를 들어, 일부 팀은 Plonk 검증기의 구현이 논문의 프로토콜과 일치한다는 것을 보여주었습니다(논문의 프로토콜 자체가 완전히 검증되지는 않았을 수 있음). 그럼에도 불구하고 저는 어떤 zkVM도 4년 이내에 3단계에 도달할 것으로 예상하지 않으며, 어쩌면 더 오래 걸릴 수도 있습니다.

주요 주의 사항: 피아트-샤미르 보안 대 검증된 바이트코드

주요 복잡성 문제 중 하나는 피아트-샤미르 변환의 보안에 대해 아직 해결되지 않은 연구 문제가 있습니다. 세 가지 보안 단계 모두 피아트-샤미르와 확률적 예측자를 절대적으로 안전한 것으로 취급하지만, 실제로는 전체 패러다임이 취약할 수 있습니다. 이는 무작위 예측 기계의 이상화된 모델과 실제 사용되는 해시 함수 사이의 불일치 때문입니다.

최악의 시나리오에서는 피아트-샤미르 관련 문제로 인해 보안 2단계에 도달한 시스템이 완전히 안전하지 않은 것으로 판명될 수 있습니다. 이는 많은 주의와 지속적인 연구가 필요합니다. 이러한 취약점을 더 잘 방어하기 위해 피아트-샤미르 변환 자체를 수정해야 할 수도 있습니다.

재귀를 사용하지 않는 시스템은 이론적으로 더 안전합니다. 왜냐하면 알려진 공격 중 일부는 재귀 증명에 사용되는 것과 유사한 회로를 포함하기 때문입니다. 그러나 이러한 위험은 여전히 해결되지 않은 근본적인 문제로 남아 있습니다.

주의해야 할 또 다른 문제는 (바이트코드로 지정된) 특정 연산 절차가 올바르게 실행되었음을 증명하더라도 바이트코드 자체에 결함이 있는 경우 증명의 가치가 극도로 제한된다는 것입니다. 강함>은 매우 제한적입니다. 따라서 zkVM의 유용성은 공식적으로 검증된 바이트코드를 생성하는 방법에 크게 의존하며, 이는 매우 큰 문제이고 이 백서의 범위를 넘어서는 문제입니다.

양자 보안에 대하여

퀀텀 컴퓨터는 적어도 향후 5년 이상은 심각한 위협이 되지 않을 것입니다. 소프트웨어 취약점은 사활이 걸린 문제입니다. 따라서 지금 우선순위는 이 백서에서 제시한 보안 및 성능 목표를 달성하는 것이어야 합니다. 비양자 보안 SNARK가 이러한 목표를 더 빨리 달성할 수 있다면 우선순위를 정하여 사용해야 합니다. 양자 내성 SNARK가 개발을 따라잡을 때까지 기다리거나 실제 위협이 있는 양자 컴퓨터가 곧 출시될 것이라는 징후가 있을 때 전환을 고려하세요.

특정 보안 수준

100비트 클래식 보안은 모든 SNARK가 귀중한 자산을 보호하기 위해 사용하는 보안 수준입니다. 소중한 자산을 보호하는 수준입니다(하지만 여전히 이 낮은 기준을 충족하지 못하는 시스템도 있습니다). 그럼에도 불구하고 이는 여전히 용납되어서는 안 되며, 표준 암호화 관행은 일반적으로 128비트 이상의 보안을 요구합니다. SNARK의 성능이 정말 최고라면 성능을 높이기 위해 보안을 낮출 필요는 없습니다.

성능 단계

현재 상황

현재 zkVM의 계산 오버헤드는 네이티브 실행보다 약 백만 배 더 큽니다. 즉, 프로그램의 기본 실행에 X CPU 사이클이 걸린다면, 올바른 실행 증명을 생성하는 데는 약 X × 1,000,000 CPU 사이클이 걸린다는 뜻입니다. 이것은 1년 전에도 사실이었으며, (약간의 오해가 있긴 하지만) 오늘날에도 여전히 사실입니다.

현재 업계에서 떠도는 소문 중 일부는 다음과 같이 오해의 소지가 있습니다.

1. "전체 이더에 대한 증명 생성 비용 전체 이더넷 메인넷에 대한 증명 생성 비용은 연간 100만 달러 미만입니다."

2. "수십 개의 GPU만으로 거의 실시간으로 이더리움 블록에 대한 증명을 생성할 수 있게 되었습니다."

3. "우리의 최신 zkVM은 이전 버전보다 1000배 더 빠릅니다."

그러나 이러한 주장은 맥락 없이 오해의 소지가 있습니다.

- 이전 zkVM보다 1000배 빠르지만 여전히 매우 느릴 수 있습니다. 여전히 매우 느릴 수 있습니다 - 이는 현재가 얼마나 좋은지보다는 예전에 얼마나 나빴는지를 더 잘 보여줍니다.

- 주 이더 네트워크의 컴퓨팅 양은 향후 10배 증가할 수 있으며, 이로 인해 현재의 zkVM 성능으로는 수요를 따라잡을 수 없게 될 것입니다.

- 소위 "실시간에 가까운" 증명 생성은 많은 블록체인 애플리케이션의 요구에 비해 여전히 너무 느립니다(예: Optimism의 블록 시간은 너무 느립니다). 옵티미즘의 블록 시간 2초는 이더리움의 12초보다 훨씬 빠릅니다).

- "24/7 실행되는 수십 개의 GPU"가 충분한 활동 보장을 제공하지 못합니다. .

- 이러한 증명 생성 시간은 일반적으로 1MB 이상의 증명 크기에 대한 것이며, 이는 많은 애플리케이션에 너무 큽니다.

- "연간 비용 100만 달러 미만"은 단순히 전체 이더 노드가 연간 약 $25의 연산만 수행하기 때문입니다. 계산을 수행하기 때문입니다.

블록체인 이외의 애플리케이션 시나리오에서는 이 계산 오버헤드가 너무 높습니다. 아무리 많은 병렬 컴퓨팅이나 엔지니어링 최적화를 하더라도 이러한 엄청난 계산 오버헤드를 보상할 수는 없습니다.

기본 목표는 네이티브 실행의 100,000배를 넘지 않는 성능 오버헤드를 갖는 것이어야 합니다. 하지만 이는 첫 번째 단계에 불과합니다. 진정한 대규모 메인스트림 채택을 위해서는 네이티브 실행의 10,000배 이하로 오버헤드를 줄여야 할 수도 있습니다.

성능 측정

SNARK 성능에는 세 가지 주요 구성 요소가 있습니다.

1. 기본 증명 시스템의 고유한 효율성.

2. 특정 애플리케이션에 대한 최적화(예: 사전 컴파일).

3. 엔지니어링 및 하드웨어 가속(예: GPU, FPGA 또는 멀티코어 CPU).

(2)와 (3)은 실제 배포에 중요하지만, 모든 증명 시스템에 적용 가능하므로 기본 오버헤드의 개선을 반드시 반영하지는 않습니다. 예를 들어, zkEVM에 GPU 가속 및 사전 컴파일을 추가하면 CPU에만 의존하는 것보다 50배 이상 빠를 수 있으며, 이는 본질적으로 효율성이 떨어지는 시스템이 같은 방식으로 최적화되지 않은 다른 시스템보다 더 나은 것처럼 보일 수 있습니다.

따라서 이 글에서는 전용 하드웨어와 사전 컴파일 없이 SNARK의 기본 성능을 측정하는 데 중점을 둡니다. 이는 일반적으로 세 가지 요소를 모두 하나의 '전체 값'으로 합산하는 현재의 벤치마킹 방법과는 대조적입니다. 이는 마치 다이아몬드 고유의 선명도를 평가하는 것이 아니라 연마하는 데 걸리는 시간으로 다이아몬드를 판단하는 것과 같습니다.

우리의 목표는 범용 증명 시스템에 내재된 오버헤드를 제거하고, 아직 깊이 연구되지 않은 기술에 대한 진입 장벽을 낮추며, 커뮤니티가 방해 요소를 제거하여 증명 시스템 설계의 진정한 진전에 집중할 수 있도록 돕는 것입니다. .

성과 단계

다음은 다섯 가지 성과 단계에 대해 제가 제안하는 마일스톤입니다. 첫째, CPU의 증명자 오버헤드를 크게 줄여야 하며, 그 이후에는 하드웨어에 더 의존하여 오버헤드를 줄일 수 있습니다. 동시에 메모리 사용량도 개선해야 합니다.

모든 단계에서 개발자는 zkVM 성능을 위해 코드를 조정할 필요가 없어야 합니다. 개발자 경험은 zkVM의 핵심 강점입니다. 성능 벤치마크를 충족하기 위해 DevEx를 희생하는 것은 벤치마킹의 목적에 어긋날 뿐만 아니라 애초에 zkVM의 목적에도 어긋납니다.

이 메트릭은 프로버 비용에 중점을 둡니다. 그러나 증명자 비용이 제한 없이 증가하도록 허용된다면(즉, 증명 크기나 증명 시간에 상한이 없다면) 모든 증명자 메트릭을 쉽게 만족시킬 수 있습니다. 따라서 다음 단계를 만족하려면 최대 증명 크기와 최대 검증 시간 모두 제한되어야 합니다.

1단계 요건: '사소하지 않은 합리적 검증 비용'

- 증거 크기: 증인 크기보다 작아야 합니다.

- 검증 시간: 증명의 검증이 프로그램의 기본 실행보다 느려서는 안 됩니다(즉, 계산의 직접 실행보다 느려서는 안 됩니다).

이것은 최소 단순성 요구 사항으로, 증명을 검증자에게 직접 전송하여 검증자가 직접 확인하는 것보다 증명 크기와 검증 시간이 나쁘지 않음을 보장합니다.

2단계 이상

- 최대 증명 크기: 256KB.

- 최대 증명 시간: 16밀리초.

이 상한은 검증 비용이 더 많이 들더라도 새로운 빠른 증명 기술을 수용하기 위해 의도적으로 느슨하게 설정되었습니다. 동시에, 이러한 상한선은 비용이 너무 많이 들어 블록체인에서 이를 사용하고자 하는 프로젝트가 거의 없는 증명을 배제합니다.

속도 1단계

단일 스레드 증명은 네이티브 실행보다 10만 배 이상 느려서는 안 됩니다 ( 이더리움 블록 증명뿐만 아니라 여러 애플리케이션의 경우), 사전 컴파일에 의존해서는 안 됩니다.

특히, 약 30억 사이클/초로 실행되는 최신 노트북을 가정할 때, 1단계에 도달하면 노트북이 30,000 RISC-V 사이클/초로 실행될 수 있다는 뜻이 됩니다. 30,000 RISC-V 사이클/초.

검증기 비용은 이전에 정의된 "사소하지 않은 합리적인 검증 비용" 기준을 충족해야 합니다.

속도 2단계

단일 스레드 증명이 네이티브 실행보다 10,000배 이상 느려서는 안 됩니다.

또한, 일부 유망한 SNARK 방법(특히 이진 도메인 SNARK)은 현재 CPU 및 GPU 제약에 의해 제한되므로 이 단계는 FPGA(또는 ASIC)로 충족할 수 있습니다.

1. FPGA가 기본 속도로 에뮬레이션하는 RISC-V 코어의 수를 계산합니다.

2. RISC-V 실행을 시뮬레이션하고 증명하는 데 필요한 FPGA의 수를 계산합니다(거의 실시간).

3. (2)의 수가 (1)의 10,000배를 초과하지 않으면 2단계가 충족됩니다.

- Prove Size. 증명 크기: 최대 256KB

- 검증 시간: 표준 CPU에서 최대 16ms.

속도 3단계

속도 2단계 달성, 1000 × 이하의 증명 오버헤드를 달성해야 하며(광범위한 애플리케이션의 경우), 자동 합성 및 공식적으로 검증된 사전 컴파일을 사용해야 합니다. 기본적으로 각 프로그램의 명령어 집합을 동적으로 사용자 정의하여 증명 생성 속도를 높일 수 있지만, 사용 편의성과 공식적인 검증이 보장되어야 합니다. (사전 컴파일이 양날의 검인 이유와 '수기' 사전 컴파일이 지속 가능한 접근 방식이 아닌 이유에 대한 자세한 내용은 다음 섹션을 참조하세요.)

메모리 1단계

2GB 미만의 RAM으로 속도 1단계 도달 및 2GB 미만의 RAM으로 속도 1단계 도달하기. 및 지식 요구 사항 제로도 충족합니다. 이 단계는 모바일 기기 또는 브라우저에 매우 중요하며 대다수의 클라이언트 측 zkVM 사용 사례에 대한 문을 열어줍니다. 예를 들어, 스마트폰은 위치 개인 정보 보호, 신원 인증 등에 사용됩니다. 증명 생성에 1~2GB 이상의 메모리가 필요한 경우 대부분의 모바일 디바이스는 실행되지 않습니다.

두 가지 중요한 참고 사항:

1. 대규모 연산(기본 실행을 위해 수조 개의 CPU 사이클이 필요)의 경우에도 증명 시스템은 2GB 메모리 제한을 유지해야 합니다. 그렇지 않으면 적용성이 제한됩니다.

2. 증명 속도가 매우 느린 경우 2GB 메모리 한도를 유지하기가 쉽습니다. 따라서 메모리 1단계가 의미가 있으려면 2GB 메모리 제한 내에서 속도 1단계에 도달해야 합니다.

메모리 2단계

에서 200MB 미만의 RAM에서 속도 1단계(메모리 1단계보다 10배 향상)로 변경합니다.

200MB로 내려가는 이유비블록체인 시나리오를 생각해 보세요. HTTPS 사이트를 방문할 때 인증 및 암호화 인증서가 다운로드됩니다. 사이트가 대신 이러한 인증서의 zk 증명을 전송하는 경우, 대규모 사이트에서는 초당 수백만 개의 증명을 생성해야 할 수 있습니다. 각 증명에 2GB의 메모리가 필요한 경우, 계산 리소스 요구 사항은 PB 수준이 될 것이며 이는 분명히 실현 가능하지 않습니다. 따라서 비블록체인 애플리케이션의 경우 메모리 사용량을 더욱 줄이는 것이 중요합니다.

사전 컴파일: 라스트 마일인가, 버팀목인가?

사전 컴파일은 특정 함수(예: 해시, 타원 곡선 서명)에 독점적으로 최적화된 SNARK 제약 조건 시스템을 의미합니다. 이더넷에서 사전 컴파일은 머클 해싱과 서명 검증의 오버헤드를 줄여주지만, 사전 컴파일에 과도하게 의존한다고 해서 SNARK의 핵심 효율성이 향상되지는 않습니다.

사전 컴파일의 문제점

1. 여전히 너무 느림: 해시 및 서명 사전 컴파일에도 zkVM은 여전히 블록체인 내부 및 외부의 낮은 핵심 개념 증명 시스템으로 인해 어려움을 겪고 있습니다. 여전히 블록체인 내부와 외부 모두에서 핵심 증명 시스템의 비효율성으로 인해 어려움을 겪고 있습니다.

2. 보안 취약성: 공식적으로 검증되지 않은 수기 사전 컴파일은 거의 필연적으로 취약하며 치명적인 보안 실패를 초래할 수 있습니다.

3. 열악한 개발자 경험: 현재 많은 zkVM은 1960년대의 프로그래밍 방식과 유사하게 개발자가 제약 시스템을 수기로 작성해야 하므로 개발 경험에 심각한 영향을 미칩니다.

4. 벤치마킹은 오해의 소지가 있다: 벤치마킹이 특정 사전 컴파일 최적화에 의존하는 경우, SNARK 설계 자체를 개선하기보다는 수기 제약 조건 시스템 최적화에 초점을 맞추는 것은 오해의 소지가 있을 수 있습니다.

5. I/O 오버헤드 및 RAM 액세스 없음사전 컴파일은 무거운 암호화 작업의 성능을 향상시킬 수 있지만, 입력/출력 전달에 많은 오버헤드가 발생하기 때문에 더 다양한 워크로드에 의미 있는 속도 향상을 제공하지 못할 수 있습니다. RAM을 사용할 수 없습니다.

블록체인 환경에서도 이더리움과 같은 단일 L1을 넘어서는 순간(예: 일련의 크로스 체인 브리지를 구축하려는 경우), 다양한 해시 함수와 서명 체계에 직면하게 됩니다. 이 문제를 해결하기 위해 지속적으로 사전 컴파일하는 것은 확장성이 떨어질 뿐만 아니라 보안상 큰 위험을 초래합니다.

저는 사전 컴파일이 장기적으로는 여전히 중요하다고 생각하지만, 자동 합성과 공식적인 검증을 거친 후에만 필요하다고 생각합니다. 이렇게 하면 치명적인 보안 위험을 피하면서 zkVM의 개발자 환경 이점을 유지할 수 있습니다. 이 관점은 3단계에 반영되어 있습니다.

예상 일정

올해 말에는 소수의 zkVM이 속도 1단계와 속도 2단계에 도달할 것으로 예상합니다. 강력> 및 <강력>메모리 1단계를 올해 말에 달성할 것입니다. 향후 2년 이내에 속도 2단계도 달성할 수 있다고 생각하지만, 새로운 연구 아이디어 없이는 달성할 수 있을지 확실하지 않습니다.

나머지 단계(스피드 3단계와 메모리 2단계)는 도달하는 데 몇 년이 걸릴 것으로 예상합니다.

이 문서에서는 zkVM의 보안과 성능 단계를 별도로 나열하고 있지만, 완전히 독립적인 것은 아닙니다. zkVM의 취약점이 계속 발견됨에 따라 이러한 취약점 중 일부를 수정하면 필연적으로 상당한 성능 저하가 발생할 것으로 예상됩니다. 따라서 성능 테스트 결과는 zkVM이 보안 2단계에 도달할 때까지 잠정적인 것으로 간주해야 합니다.

zkVM은 영지식 증명을 진정으로 보편화할 수 있는 큰 잠재력을 가지고 있지만 아직 초기 단계에 있으며 보안 문제와 심각한 성능 병목현상으로 가득 차 있습니다. 시장의 과대광고와 마케팅 과대광고로 인해 실제 진전을 측정하기가 어렵습니다. 명확한 보안 및 성능 마일스톤을 통해 안개를 걷어낼 수 있는 로드맵을 제공하고자 합니다. 언젠가는 도달하겠지만 연구와 엔지니어링에 시간과 지속적인 노력이 필요할 것입니다.