보안 대 신뢰 부족: ZK 프로토콜에서 균형을 선택하는 방법

이 기사는 기계로 번역되었습니다
원문 표시

최근 zkSync와 Polygon은 각자 zkEVM을 출시하며 업계에 큰 반향을 일으켰습니다. 이는 zkEVM의 보안 및 탈중앙화 대한 광범위한 커뮤니티 토론을 촉발했습니다. 최근 마무리된 ETHDenver 행사에서 IOSG는 보안 중심 행사(Stay SAFU, Security Day)를 개최했으며, 이 행사에는 영지식 증명 분야의 선도적인 프로젝트들이 참여했습니다. 이들은 영지식 증명 프로토콜 메커니즘 설계 및 엔지니어링에 대한 자체 보안 원칙과 새로운 접근 방식, 그리고 설계 과정에서 발생한 다양한 상충 관계를 공유했습니다.

다음은 게스트들이 공유한 독창적인 통찰력입니다. 참여자는 다음과 같습니다.

IOSG Ventures의 파트너인 Queenie Wu(진행자)

zkSync의 공동 창립자 알렉스 글루초프스키;

스크롤의 공동 창립자이자 연구 책임자인 예 장(Ye Zhang)

Taiko의 최고운영책임자(COO), 맷 파인스톤

미하일 코마로프, 닐 재단 설립자

Risc0의 창립자 Brian R;

질문 1: 영지식 증명은 구축 중인 시스템의 보안을 어떻게 강화합니까? 반면, 영지식 증명을 도입하면 어떤 보안 문제가 발생합니까?

[브라이언 R]

저는 Risk Zero의 CEO인 Brian Redford입니다. 저희는 Risk-V Micro Architecture를 기반으로 구축된 Risk Zero zkVM을 개발했으며, 이를 통해 ZK 시스템 내에서 임의 코드 실행이 가능합니다. 또한 ZK 컨텍스트 내에서 임의 코드를 실행할 수 있는 Bonsai라는 Layer 2 네트워크도 구축하고 있습니다. 이를 ZK 가속기 라고 생각해 보세요. ZK가 보안을 강화하는 방식은 특정 애플리케이션에 따라 다르다고 생각합니다. 물론, 전 세계 어디에서나 검증할 수 있는 계산을 수행하고 증명을 생성할 수 있는 능력은 블록체인 보안의 패러다임을 완전히 바꿔놓습니다. 더 이상 동일한 계산을 반복해서 수행할 필요가 없으며, 복잡한 메커니즘(예: 경제적 메커니즘)에 의존하여 전체 시스템의 보안을 보장할 필요가 없습니다.

[미하일 코마로프]

저는 Nil의 설립자 미하일 코마로프입니다. 저희는 zk-EVM 컴파일러와 같은 진행 중인 ZK 프로젝트를 위한 인프라를 제공합니다. 이 컴파일러는 고급 언어를 회로로 컴파일하여 고급 언어로 정의된 모든 계산을 실행 없이 간단한 회로만으로 증명할 수 있도록 합니다. 또한, zkSNARK/STARK 증명을 생성하려는 프로젝트를 위한 탈중앙화 시장을 활용할 수 있습니다).

본질적으로, 우리는 개발자에게 필요한 인프라입니다. 그 자체로 보안을 강화하는 것은 아니지만, 전반적인 보안을 강화합니다. 브라이언이 언급했듯이, 프로토콜이 신뢰가 필요 없는 환경에서 실행되도록 하는 신뢰 가정을 제거함으로써 보안을 강화합니다. 핵심은 신뢰 가정을 더욱 줄이는 것입니다. 이것이 바로 보안을 강화하는 방법입니다. 프로젝트에서 영지식 증명을 도입했더라면 작년에 발생한 보안 사고 중 일부를 피할 수 있었을 것이라고 생각합니다.

[맷 파인스톤]

저는 Taiko의 Matt입니다. 저희는 이더 호환되는 ZK Rollup을 운영하고 있습니다. 저희는 이더 과 EVM의 호환성을 극대화하기 위해 최선을 다합니다. 보안 측면에서 저희를 차별화하는 요소는 검증되고 검증된 이더 구성 모듈, 클라이언트, 그리고 스마트 컨트랙트 패턴에 대한 높은 의존성입니다. Mikhail이 언급했듯이 ZK는 신뢰 가정을 줄이거나 프로토콜/증명 수준으로 전환합니다. "신뢰"는 더 이상 동기 부여된 개인이 아닌, 수학적 증명을 기반으로 구축된 수학과 프로토콜, 그리고 애플리케이션에 있습니다. ZK Rollup에는 ZK 외에도 다양한 보안 고려 사항이 있습니다.

저희는 이더 의 보안 부분을 최대한 재활용하여 보안을 유지하고 있으며, ZK는 시간이 지남에 따라, 그리고 실전 테스트를 거치면서 매우 강력한 시스템이 될 것이라고 생각합니다.

[예 장]

안녕하세요 여러분, 저는 예입니다. Scroll에서 일하고 있습니다. 먼저 Scroll을 간략하게 소개해 드리겠습니다. Scroll은 이더 의 확장 솔루션으로, 이더 과 높은 호환성을 자랑합니다. 사용자는 애플리케이션과 상호 작용할 수 있으며, 개발자는 코드를 복사하여 붙여넣고 Scroll로 마이그레이션하는 것만으로 스마트 계약을 배포할 수 있습니다. 이더 보다 빠르고 저렴하며, 처리량이 높고 보안이 더욱 강화되었습니다. 저희는 증명 시스템의 단일 실패 지점을 방지하기 위해 증명 시스템(탈중앙화 증명자 네트워크)을 탈중앙화 할 것입니다. 이는 ZK Rollup이 앞으로도 오랫동안 탈중앙화 될 것이기 때문에 탈 탈중앙화 향한 첫걸음입니다. 수학 및 암호학에 대한 깊은 믿음이 있더라도 증명자에 의존하기 때문에 이러한 단일 실패 지점에 직면할 수 있습니다.

탈중앙화 첫 번째 단계는 증명 시스템을 탈중앙화 더욱 신뢰할 수 있도록 하는 것입니다. ZK의 보안과 관련하여, 다른 발표자들도 ZK가 매우 강력한 공개 검증 가능성을 제공한다는 점을 이미 언급했다고 생각합니다. 기본적으로 누구나 계산을 수행하고 증명을 실행할 수 있으며, 그 증명을 검증하고 동일한 보증을 받을 수 있습니다. 수백만 개의 노드가 있는 경우, 모든 노드는 초기 계산 대신 검증 알고리즘만 다시 실행하면 되므로 확장성이 확보됩니다. 이것이 바로 ZK 기술의 힘입니다. 잠재적인 어려움에 대해 말씀드리자면, 시스템이 전적으로 수학적 연산에 의존하는 경우 제약 조건 누락과 같은 오류가 발생할 수 있습니다. 이것이 바로 ZK가 보안을 강화하기 위해 다양한 접근 방식을 취하는 이유입니다. 예를 들어, 커뮤니티 중심의 개발 방식을 채택했습니다. 처음부터 전체 개발 프로세스를 오픈소스로 공개하여 이더 커뮤니티와 ZK 자체 커뮤니티 모두의 감사를 거쳐 더 높은 기준을 설정했습니다. 이를 통해 신뢰를 최소화하고 보안을 강화합니다.

[알렉스 글루코프스키]

저는 알렉스 글루초프스키이고, zkSync 프로토콜을 개발한 Matter Labs의 CEO입니다. 저희는 ZK EVM과 호환되는 ZK Rollup인 zkSync Era Network를 구축하고 있습니다. EVM과 동일한 Rollup과는 약간 다른 접근 방식을 취하고 있습니다. 저희는 실용적인 접근 방식을 취하고, 개발자가 기존 애플리케이션을 쉽게 포팅하고 기존 도구에서 실행할 수 있도록 호환되는 것부터 시작합니다. 하지만 궁극적인 ZK 환경은 다릅니다. 기존 기술에 얽매여 있다면 ZK 시스템의 최대 용량을 확보하기 어려울 것입니다. 이는 저희의 사명이 블록체인을 실제 규모로 확장하여 향후 10억 명의 사용자를 블록체인으로 유도하고 새로운 가치 인터넷을 구축하는 것이기 때문에 중요합니다. 수백만 또는 수십억 명의 사용자를 고려할 때, 수십억 건의 거래가 누적됨에 따라 비용이 매우 중요해지므로 비용을 절감하는 것이 매우 중요합니다.

이것이 보안 강화 방식에 어떤 영향을 미칠까요? 정말 흥미로운 질문입니다. 보안을 어떻게 강화할지, 또는 다른 요인을 고려할 때, 대안을 비교하고 싶어 하지 않나요? 제 기준은 무엇인가요? ZK를 사용하는 것의 대안은 무엇일까요? ZK Rollup 이전에 사용 가능했던 다른 확장 기술, 예를 들어 Optimistic Rollup, 사이드체인, Plasma 등이 대안이 될 수 있습니다. 이러한 기술은 새로운 신뢰 가정을 제시합니다. 만약 저희의 목표가 10억 명의 사용자로 확장하는 것이고, 단순히 처리량을 늘리는 것이 아니라 자체 주권, 자체 보관, 허가 불필요, 그리고 완전히 신뢰할 수 없는 시스템을 유지하면서 가치를 확장하는 것이라면, ZK는 이를 달성할 수 있는 유일한 방법입니다.

Q2: 다양한 유형의 zkEVM을 비교할 때, 일반적으로 확장성과 호환성에 중점을 둡니다(Vitalik이 자세한 비교를 했습니다: https://vitalik.ca/general/2022/08/04/zkevm.html). 여기에 보안 측면을 추가한다면, zkSync Era, Scroll, Taiko는 서로 다른 메커니즘 설계에서 발생할 수 있는 잠재적 보안 리스크 측면에서 어떻게 비교될까요?

[알렉스 글루코프스키]

이전 발표자가 언급했듯이 보안을 보장하려면 이러한 복잡한 시스템의 많은 구성 요소를 암묵적으로 신뢰해야 합니다. 예를 들어 컴파일러가 생성한 코드를 신뢰하고, 프로그래밍한 로직을 실행한다고 가정합니다. Solidity에서는 왜 이를 신뢰해야 할까요? 공식적으로 정의되어 있지 않으므로 컴파일러가 여러 버전에서 올바르게 동작한다고 믿기만 하면 됩니다. 저희는 이 문제를 반드시 해결해야 한다고 생각합니다. 그래서 LLVM 프레임 기반 컴파일러를 개발하기 시작했습니다. 이 컴파일러는 프런트엔드 중 하나로 Solidity를 지원하고, 정적 코드 분석 및 보안 검사를 위한 다양한 도구를 갖춘 이 성숙한 프레임 사용합니다. 백엔드는 zkVM 가상 머신입니다. 또한 Rust와 같이 다른 보안 환경에서 이미 사용되는 더욱 성숙한 언어나 Move와 같이 이중 지불과 같은 보안 문제를 방지하는 보안 고려 사항이 추가된 새로운 언어도 지원할 수 있습니다. 간단히 말해, 복잡성에도 불구하고 이 문제를 다양한 수준에서 해결해야 합니다.

[예 장]

다양한 접근 방식과 그 배경에 대해 이야기해 보겠습니다. 저희는 EVM 바이트코드 수준에서 호환성 솔루션을 구축하고 있습니다. 기본적으로 EVM 바이트코드와 호환됩니다. 이는 zkSync의 접근 방식과는 다르며, 저희는 컴파일러를 신뢰해서는 안 된다고 생각합니다. 그렇기 때문에 Solidity 컴파일러를 신뢰합니다. 아직 미숙하지만 블록체인 환경에서는 비교적 성숙했습니다. 이전에 Solidity와 LLVM을 사용해 본 사람은 아무도 없습니다. Solidity 컴파일러는 실제로 검증되었고, DeFi의 많은 스마트 계약이 Solidity 개발자들에 의해 테스트되었기 때문에 더 나은 표준이라고 생각합니다. 따라서 이 컴파일러 표준, Solidity 컴파일러 표준, 그리고 EVM Yellow Paper의 정의를 준수하는 것이 시스템 보안을 보장하는 최선의 방법이라고 생각합니다. 회로 관점에서 보면 컴파일러 문제에 대해 걱정할 필요가 없습니다. 자체 컴파일러를 구축할 필요도 없습니다. 기존 인프라를 활용하여 제대로 실행되는지 확인하기만 하면 됩니다.

저희는 컴파일러와 LLVM 지원 백엔드를 구축하는 것보다 zkEVM 바이트코드 호환성을 해결하는 데 시스템 구축의 복잡성을 집중하는 것을 선호합니다. zkEVM 외에 컴파일러를 추가로 구축하고 싶지 않습니다. 또 다른 고려 사항은 개발자 경험을 절대적으로 중시한다는 것입니다. Layer 2는 EVM을 확장하기 위해 구축되었으며, 현재 EVM은 이미 Solidity 코드와 애플리케이션 대량 가득 차 있습니다. 저희는 개발자들이 보안을 보장하면서 저희 시스템으로 원활하게 마이그레이션할 수 있기를 바랍니다. 이것이 현재 EVM에 더 많은 고급 기능을 추가할 계획이 없는 이유입니다.

이 표준을 준수함으로써 이더리움은 최적의 성능과 이를 기반으로 구축된 시스템의 적시 제공을 보장하는 동시에 진정한 확장성을 확보할 수 있습니다. 동시에, 개인정보 보호 및 확장성을 다루는 Type 1 및 Type 2 zkEVM을 포함하여 이더 내에서 다양한 오픈소스 구현을 추진하고 있습니다. 저희는 처음부터 오픈소스 접근 방식을 채택해 왔습니다. 이더리움 zkEVM의 개발 및 진화에 깊이 집중하고 있습니다. 저희는 개발의 절반을 주도하고 팀의 일원이기 때문에 전체 시스템이 완전히 준비되는 데 얼마나 시간이 걸릴지 정확히 알고 있습니다. 이것이 바로 저희가 이러한 접근 방식을 취하는 이유입니다. 먼저 제품을 준비하고 커뮤니티와 소통한 후, 이더리움의 궁극적인 목표를 어떻게 발전시킬지 고민합니다.

[맷 파인스톤]

두 가지 훌륭한 답변입니다. Taiko와 Scroll의 솔루션이 더 유사하고, 새로운 컴파일러도 도입하지 않았습니다. Alex의 답변이 마음에 듭니다. 블록체인 환경에서 안전한 대안은 무엇일까요? 이더 모두 동의할 것입니다. 저희는 Yellow Paper에 따라 이더 구성 요소를 수정하는 대신 재사용하여 구현했습니다. 데이터 저장 구조와 같이 EVM 외부의 이더 이더 구성 요소도 실제로 검증되었습니다.

물론, 항상 상충되는 측면이 있습니다. 알렉스는 10억 명의 사용자와 초저비용, 그리고 가치를 유지하는 확장성에 대해 이야기했습니다. 비용 측면에서 더 큰 희생을 감수할 수도 있지만, 실전에서 검증된 EVM과 이더 표준을 고수합니다. 또한 예 장이 언급한 실용성과 출시 속도 측면에서도 몇 가지 고려 사항을 검토합니다.

ZK의 맥락에서 특정 해시 함수나 데이터 저장 구조와 같은 일부 접근 방식은 구현하기 어렵습니다. Merkel Patricia Tree를 Verkle Tree로 대체하는 것과 같은 효과에 대한 확신이 없기 때문에 이러한 변경은 하지 않습니다. 이는 이미 이더 로드맵에 포함되어 있음에도 불구하고 말입니다. 저희는 이미 테스트되고 검증된 구성 요소에 더 큰 확신을 가지고 있습니다. 시스템의 복잡성은 이더 의 EVM 및 기타 구성 요소를 재구축하는 데 있는 것이 아니라, EVM과 호환되는 ZK를 완벽하게 구현하는 데 있습니다. 이를 완료하는 데는 더 오랜 시간이 걸리며, Scroll보다 사용성을 확보하는 데 필요한 절충안을 더 오래 고려해야 합니다. 그러나 저희의 구현 방식은 더 높은 수준의 보안을 보장합니다.

[미하일 코마로프]

이더 의 검증된 특성 덕분에 이러한 모든 시스템을 재사용하고 새로운 가정의 수를 줄일 수 있습니다. 하지만 소수의 사람들만 진지하게 고려하는 몇 가지 보안 문제가 있으며, 저희의 목표는 이러한 문제를 해결하는 것입니다. 첫 번째는 컴파일러를 신뢰해야 한다는 것입니다. 또 다른 문제는 Type 1 EVM 호환성과 같은 완전한 EVM 호환성을 원한다면, 특정 도메인에서 특정 표현식을 회로로 구현할 때 어떤 형식을 가져야 하는지 파악하여 회로의 모든 EVM 명령어를 수동으로 다시 구현해야 한다는 것입니다. 이는 매우 복잡하고 오류가 발생하기 쉬운 수동적인 과정입니다. 저희도 직접 이 작업을 수행하여 회로를 망친 경험이 있으므로, 이것이 얼마나 심각한 문제인지 잘 알고 있습니다.

이러한 문제가 반복되지 않도록, 그리고 누구도 이러한 실수를 하지 않도록, 저희는 모든 연산 코드를 수동으로 다시 구현하는 대신, 실전에서 검증된 EVM 구현을 사용하여 회로를 컴파일할 수 있도록 함으로써 이러한 보안 가정을 ​​제거하고자 노력하고 있습니다. 저희의 목표는 수동으로 다시 구현하는 대신 LLVM 컴파일러를 사용하여 컴파일하여 보안 가정을 ​​최소화하는 것입니다. 이는 제거되어야 할 또 다른 보안 가정이며, zkEVM에서 이 문제를 해결할 것입니다.

[브라이언 R]

RiscV와 같은 시스템에서 geth를 실행하면 Mikhail이 언급한 문제를 해결할 수 있습니다. 실제로 저희는 Go에 대한 지원을 추가했습니다. RiscZero VM을 구축하고 설계했으며, RiscV 명령어 세트를 선택한 이유는 형식적인 정의가 있고 매우 가볍기 때문입니다. RiscV 회로의 보안 범위가 명시되어 있으며, 구현이 RiscV 사양을 준수하는지 증명하기 위해 형식적인 검증 방법을 통합하기 위해 대량 작업이 수행되었습니다. 저희는 이 간단한 시스템의 암호화가 올바른지 확인하는 데 집중했고, 그 후 EVM을 실행하여 실제로 작동하는지 확인했습니다. 물론 이러한 접근 방식에는 성능 저하가 있습니다. 예를 들어 ERC20 토큰을 전송하는 데 약 1분이 걸립니다.

질문 3: Alex가 방금 언급했듯이, 시스템의 어느 부분에서든 업그레이드하거나 다른 솔루션을 선택할 수 있습니다. 그렇다면 시스템의 업그레이드 가능성을 보장하고 매우 안전한 방식으로 구현하려면 어떻게 해야 할까요?

[브라이언 R]

네, ZK에서 업그레이드 가능성은 매우 중요한 주제라고 생각합니다. 저희 관점에서는, 네트워크가 구축되지 않았고 경제적 가치 대량 않았기 때문에 기술 스택에서 적절한 추상화를 구축하는 데 대량 시간을 투자했습니다. 해시 함수, 유한체, 증명 체계를 전환하거나 PLONK와 같은 새로운 기술을 스택에 추가할 수도 있었습니다. 이것이 바로 저희가 RiscV를 주요 "명령어 세트"로 선택한 또 다른 이유입니다. RiscV는 매우 깔끔한 추상화 시스템이기 때문입니다. 따라서 원하는 것은 무엇이든 대체할 수 있습니다. LLVM도 분명히 매우 유사한 특성을 가지고 있습니다.

[맷 파인스톤]

네, 업그레이드는 중요한 주제이며, 시스템 신뢰의 문제로 볼 수 있습니다. 시스템 구현에는 취약점이 있을 수 있으며, 사용자를 리스크 에 빠뜨리거나 시스템 구축자 또는 취약점을 악용할 수 있는 특정 행위자를 신뢰할 수 있습니다. 업그레이드는 특정 수준에서 보안과 신뢰 부족 사이의 균형을 찾는 것입니다. 시스템에 대한 신뢰가 높아짐에 따라 일부 신뢰할 수 있는 행위자를 제거할 수 있습니다. 이러한 조치의 목적은 제거이므로 신뢰할 수 있는 행위자에 대해서는 매우 신중해야 합니다. 이처럼 매우 복잡한 시스템의 경우 조기에 개입하는 것이 최선입니다. Alex와 Matter Labs 팀은 이와 관련하여 훌륭한 사례를 제시했다고 생각합니다. 그들은 훌륭한 안전 위원회와 시간 지연 메커니즘을 갖추고 있습니다.

그렇다면 업그레이드를 위한 적절한 주기는 무엇일까요? 매우 중요한 질문입니다. 완전히 신뢰할 수 없는 시스템은 종종 매우 복잡하고 많은 새로운 기능을 도입하기 때문에 더 많은 사용자가 이러한 시스템에 편안함을 느낄지, 아니면 선의의 참여자들을 신뢰할지 궁금합니다. 이는 매우 인간적인 질문이며, 다중 증명과 같은 몇 가지 기술적 해결책이 분명히 있는데, 이는 좋은 선택이 될 수 있습니다. Optimism과 유사한 구성 요소의 일부 디자인을 재사용하는 것이 가능하다고 생각합니다. 유효성 증명에 문제가 있는 경우, Optimistic Rollup 구현을 재사용하면 이더 동등한 환경에서 작동하는 사기 방지 시스템을 더 쉽게 개발할 수 있습니다. 사기 증명과 유효성 증명을 혼합하여 사용할 수 있으며, 이의가 있는 경우 업그레이드 기능이나 어떤 유형의 거버넌스 솔루션을 통해 해결할 수 있습니다.

[미하일 코마로프]

설명해 드리겠습니다. 방금 이 문제에 대해 좀 생각해 봤습니다. 질문을 제대로 이해하지 못해서 걱정입니다. 업그레이드 문제는 어디에 있는 걸까요? 회로를 다시 조립하면 되는 건가요? 그럼 업그레이드 문제는 무엇일까요?

[예 장]

저희 관점에서는, 우선 새로운 회로를 컴파일하는 것은 증명 키, 검증 키, 그리고 여러 온체인 스마트 컨트랙트에 영향을 미치기 때문에 빈번하게 수행할 수 없습니다. 따라서 다중 증명 방식을 고려하고 이중 검증과 같은 메커니즘을 추가하는 방안을 검토하고 있습니다. 이 문제를 해결할 수 있는 방법은 여러 가지가 있으며, Matt가 언급했듯이 낙관적 사기 증명과 직접 통합하는 것은 고려하지 않고 있습니다. 그렇게 하면 확정성이 더욱 길어질 것이기 때문입니다. 다른 접근 방식을 모색하고 있으며, 곧 이더리움 리서치(이더 Research)에 추가적인 보장을 추가하는 방법에 대한 제안을 제출할 예정입니다.

예를 들어, 저스틴 드레이크는 Intel SGX(TEE 환경)를 추가 보호 수단으로 사용하여 보안 보장을 엄격하게 강화할 것을 제안했습니다. 다른 거버넌스 방식도 가능하며, 보안 위원회와 시간 지연 방식이 유망하다고 생각합니다. 저희도 이 문제를 고려하고 있습니다. 이는 상충 관계이며, 시스템 업그레이드는 장기적인 프로세스이기 때문에 대부분의 롤업에서 이 업그레이드 문제를 완전히 극복하는 데 더 오랜 시간이 걸릴 것으로 예상됩니다. 저희는 이 문제를 면밀히 모니터링하고 연구하고 있습니다.

[알렉스 글루코프스키]

업그레이드 가능성이 왜 그렇게 중요한 문제인지에 대한 맥락을 말씀드리겠습니다. 예를 들어, 데스크톱에서 실행되는 모든 프로그램의 경우 새 버전을 다운로드하여 설치하기만 하면 됩니다. 그렇다면 업그레이드의 문제점은 무엇일까요? 문제는 블록체인이라는 맥락에서 신뢰할 수 없는 시스템을 구축하려고 하지만, 경우에 따라 업그레이드 필요성이 그 신뢰를 약화시킬 수 있다는 것입니다. 레이어 1의 경우 이는 문제가 되지 않습니다. 이더 업그레이드하려면 새 클라이언트를 다운로드하고 설치한 다음, 모두가 포크 조정하면 됩니다.

그런 다음 포크 일정을 잡고 날짜를 정한 후 특정 블록 번호에 포크. 그러면 업그레이드가 마음에 들지 않는 사람은 누구나 이전 버전의 기존 브랜치에 남을 수 있습니다. 이 업그레이드 경로는 완전히 신뢰할 수 없습니다. 정직한 다수나 신뢰할 수 있는 참여자에게 의존하지 않습니다.

문제는 레이어 2 맥락에서 발생합니다. 롤업을 구축하는 경우 레이어 1 스마트 계약에 의존합니다. 이 스마트 계약은 변경 불가능할 수 있으며, 특정 회로에 대한 특정 고정 함수와 검증 키가 이미 내장되어 있습니다. 문제는 버그가 발생하면 아무것도 할 수 없다는 것입니다. 그렇다면 버그가 발생하거나 수정하고 싶을 때 어떻게 해야 할까요?

저희는 zkSync 1.0(zkSync Lite)의 취약점을 공개했습니다. 이 취약점은 업그레이드 가능성에 시간 제한을 두어 팀이 새 버전을 제안할 수 있도록 했습니다. 사용자가 새 버전을 원하지 않을 경우, 레이어 1에서 자산을 인출할 수 있도록 몇 주라는 시간이 주어졌습니다. 저희는 이러한 인출을 용이하게 하기 위해 Trustless 메커니즘을 구축했습니다. 그러나 이 시간 제한에 강제로 참여하게 되면서 문제를 해결할 수 없었습니다. 그래서 저희는 타협안을 마련하여 보안 위원회(Security Council)라고 불리는 독립 위원회를 설립했습니다. 다양한 커뮤니티와 프로젝트에서 활동하는 이더 커뮤니티의 저명한 구성원 15명을 초대했습니다.

팀은 계약을 통제하지 않습니다. 업그레이드를 제안할 수만 있고, 안전보장이사회가 결정을 내려 업그레이드 속도를 높일 가능성이 있습니다. 그러나 이론적으로는 여러 개인이 악성 버전을 즉시 설치할 수 있기 때문에 이는 여전히 바람직하지 않습니다. 그들은 원하지 않더라도 특정 행위자에 의해 강제로 설치될 수 있으며, 이러한 가능성도 배제할 수 없습니다. 따라서 영지식 증명을 최대한 활용하고 검증 절차에 참여하는 신뢰할 수 있는 당사자가 아닌 수학과 오픈 소스 코드에만 의존한다면, 궁극적으로 완전히 신뢰할 필요가 없는 메커니즘을 구현할 수 있습니다.

현재 저희는 팀이 시간 제한이 있는 업그레이드 제안을 하고, 안전보장이사회가 개입하여 스마트 계약을 동결 후 레이어 1에서 소프트 포크 권고하는 더 나은 접근 방식을 고려하고 있습니다. 이를 위해서는 레이어 1과의 협력이 필요하며, 레이어 2 프로토콜이 커뮤니티에서 실제로 포크 하고 새 버전을 설치할 만큼 충분히 크고 중요해야 합니다. 레이어 1만으로는 모든 소규모 프로토콜에 대해 이러한 작업을 수행할 수 없기 때문에, 이더 과 같은 주요 시스템 수준의 프로토콜이어야 합니다.

이는 신뢰할 수 없는 업그레이드 가능성을 높이고 첫 번째 계층의 심각한 취약점으로부터 보호하기 위한 현재로서는 최선의 메커니즘입니다. 하지만 여전히 시의성 문제와 같은 문제가 발생합니다. 이러한 문제가 발생하면 프로토콜이 일정 기간 동안 중단됩니다. 비자와 페이팔에서 블록체인 결제에 이러한 대규모 롤업을 사용하는 방식으로 전환했다고 가정해 보겠습니다. 갑자기 사용자 자금이 동결 되고, 아무도 결제를 할 수 없게 되며, 며칠 동안 업그레이드를 조정해야 합니다. 이는 심각한 문제입니다. 현재로서는 더 나은 해결책을 가지고 있지 않으며, 더 나은 해결책을 기대하지도 않습니다. 좋은 아이디어가 있으시면 저희에게 연락해 주시면 자세히 논의해 보겠습니다.

Q4: 반복적으로 언급된 핵심 단어는 "신뢰할 수 없음(Trustless)"입니다. 우리 모두 알다시피, 현재 시스템의 가장 중요한 구성 요소는 여전히 중앙 집중화되어 있습니다. 중앙 집중화에서 탈 탈중앙화 전환 과정에서 우리는 어떤 보안 문제에 직면하게 될까요?

[알렉스 글루코프스키]

저는 이(Trustless) 방식이 보안을 강화할 것이라고 생각합니다. 추가적인 보호 계층을 제공할 것입니다. 첫째, ZK Rollup은 각 블록에 대한 유효성 증명을 제공해야 하지만, 예를 들어 특정 제약 조건을 무시하는 경우 문제가 될 수 있습니다. 여기에 더해, 추가적인 보호 계층을 제공하는 지분증명 합의 메커니즘에서 제공하는 서명도 필요합니다. 시스템을 손상시키려면 악의적인 공격자가 먼저 취약점을 찾은 다음, 다수의 검증자와 공모하여 이를 악용해야 합니다.

공격자가 이미 온체인 장악하고 있거나 대량 의 토큰을 구매해야 할 가능성이 높기 때문에 이는 상대적으로 가능성이 낮습니다. 이를 통해 다른 사람들이 동일한 취약점을 발견하고 Immunefi 또는 다른 곳에 보고하여 팀이 문제를 해결할 수 있는 충분한 시간을 확보할 수 있습니다. 또는 완전히 공개되어 누구든 해킹하여 보상을 받을 수 있는 허니팟을 여러 개 동시에 운영할 수도 있습니다. 전반적으로 이는 전체 시스템에 두 가지 보호 요소를 제공합니다. 더 나아가, 여기에 더 많은 보호 요소를 추가할 수도 있습니다.

이 시점에서 저는 완전히 신뢰할 수 없다고 주장하는 ZK 롤업을 신뢰하지 않을 것입니다. 저에게는 엄청난 리스크 될 것입니다. 그런 ZK 롤업에 제가 감당할 수 있는 손실보다 많은 자산을 투자하지 않을 것입니다.

제가 가장 좋아하는 사례는 보잉 737 맥스 사고입니다. 사고의 원인은 그들이 주의를 돌리려 했던 소프트웨어 문제가 아니라, 항공기의 단일 센서에 대한 무책임한 의존이었습니다. 항공 산업은 오랜 역사를 가지고 있으며 수많은 기술적 변화를 거쳐 왔고, 단일 시스템에 대한 의존은 용납될 수 없다는 것이 널리 받아들여지고 있습니다. 그러나 보잉 737 맥스 생산 과정에서 비용, 납기 등 여러 가지 이유로 안전 시스템 설계를 희생했고, 결국 사고로 이어졌습니다. 따라서 저희는 고장 가능성을 줄이기 위해 최소 두 개의 완전히 독립적인 안전 요소를 확보하기 위해 항상 노력합니다.

[예 장]

저희는 장기적인 관점을 가지고 ZK Rollup 탈중앙화 로드맵에 접근합니다. Sequencer와 Prover 중 어느 것을 먼저 탈중앙화할지, 그리고 ZK Rollup의 탈중앙화 어떻게 정의할지에 대한 저희만의 생각이 있습니다. 궁극적으로 Sequencer와 Prover를 모두 탈중앙화 할 것이라고 생각합니다. 하지만 저희는 순서 약간 다르며, Prover를 먼저 탈중앙화 싶습니다. 보안이 핵심적인 이유입니다. zkEVM이 완전히 성숙하고 견고해지기 전에 Sequencer를 먼저 탈중앙화 경우, 누군가 취약점을 발견하고 거짓 증명을 제출할 경우, Sequencer가 이를 승인하여 블록으로 생성하여 시스템에 잠재적인 손상을 입힐 가능성이 있습니다.

따라서 저희는 초기에는 중앙 집중식 시퀀서를 유지할 것입니다. zkEVM은 취약성이 높고 매우 복잡한 시스템입니다. 따라서 정확하고 효율적인 블록 생성을 보장하기 위해 적어도 초기 단계에서는 중앙 집중식 순서 제어를 유지하고자 합니다.

탈중앙화 해야 하는 또 다른 이유는 많은 하드웨어 회사들이 zkEVM의 효율성을 높일 방법을 모색하고 있기 때문입니다. Prover를 탈중앙화 결정하면, 그들은 시스템 코드 최적화에 참여할 것입니다. ZK ASIC이 출시되는 데 1년 이상 걸릴 수 있다는 것은 누구나 알고 있습니다. Prover를 먼저 탈중앙화 하면, 그들은 우리 시스템을 개발하는 데 더 적극적으로 참여하여 시스템의 효율성을 높일 것입니다. Sequencer의 탈중앙화 추후 계획입니다.

여기에는 더 복잡한 요소가 고려됩니다. 증명자와 시퀀서가 서로 다른 두 그룹에 할당되는 경우, 인센티브 체계는 매우 신중하게 설계되어야 합니다. 예를 들어, 두 당사자에게 할당되는 보상의 비율은 합리적이고 균형적이어야 합니다.

그 외에도 여러 가지 보안 조치를 시행하고 있습니다. 예를 들어, 저희가 구축하고 있는 접근 방식은 오픈 소스이며, 외부 감사 뿐 아니라 내부 보안 감사 도 실시하고 있습니다. 저희는 매우 강력한 보안팀을 보유하고 있습니다. 또한, 형식 검증과 같은 도구와 같은 보안 솔루션 구축에 더 많은 참여를 장려하기 위해 다양한 보조금을 제공합니다. 저희 팀은 ConsenSys ZKEVM과 Aztec 회로에서 취약점을 발견하기도 했습니다. 저희는 전체 생태계의 보안을 강화하기 위해 노력하고 있습니다.

[맷 파인스톤]

Taiko는 이 과제에 더 빨리 직면할 수도 있습니다. 둘 다 어느 정도 탈중앙화 되어 있지만, 실제로는 EVM, 가스 스케줄, 상태 트라이를 포함하여 이더 과 동일한 접근 방식을 유지할 계획입니다. 또한 Ethos와 기타 탈 탈중앙화(저희가 부르는) 시퀀서 제안자 및 증명자도 고려하고 있습니다. 몇 달 전 첫 번째 테스트넷에서 약 2,000명의 독립적인 개인 또는 주소가 허가 없이 블록을 제안했습니다. 악의적인 블록이 있을 수 있지만, 이는 또한 탈중앙화 의 약속이기도 합니다. 저는 이것이 점진적인 탈중앙화 아니라 점진적인 효율성 향상이라고 생각합니다. 효율성을 어느 정도 포기해야 하기 때문입니다. 제안자는 중복 블록을 생성하여 일부 중복 거래를 발생시키고 레이어 1에 지불된 귀중한 블록 공간을 ETH로 희생할 수 있습니다. 일부는 환불을 받을 수 있지만, 다른 일부는 그냥 건너뛸 것입니다.

다음 테스트넷에서 탈중앙화 즉시 달성하는 것은 현실적으로 불가능합니다. 허가 없는 증명자는 테스트넷 환경에서는 Sybil어택 공격으로 인해 어려움을 겪습니다. Sybil 공격은 제안된 블록을 스팸으로 채울 수 있는 공격이며, 증명자는 이를 증명하기 위해 실제 컴퓨팅 리소스를 소모해야 하지만 실질적인 수익은 없습니다.

따라서 허가된 제안자(Permissioned Proposers)를 사용하여 모든 탈중앙화 증명자(Prover)가 블록을 제출하고 그에 상응하는 보상을 받을 수 있도록 할 것입니다. 이는 매우 중요합니다. 또한, 시스템 장애가 발생하여 증명자가 유효성 증명을 제출하고 일관성 없는 증명도 제출될 경우, 스마트 계약은 이를 인지하고 중단됩니다. 스마트 계약은 서로 다른 블록에 두 개의 올바른 유효성 증명이 존재하는 이유를 파악하고 즉시 프로세스를 중단시켜 시간 지연을 유발합니다. Alex가 언급했듯이, 현재로서는 완전히 허가가 없고 신뢰가 없는 구현을 확신할 수 없습니다. 균형을 맞추기 위해 노력해야 합니다.

[미하일 코마로프]

저희는 처음부터 이 문제를 고려했습니다. 어떤 사람들은 처음에는 하향식 접근 방식으로 접근하여 Rollup을 만든 후, Sequencer를 탈중앙화 하고 Prover를 한 단계씩 탈중앙화 등 탈중앙화 순서를 고려했습니다. 이와는 대조적으로, 저희는 다른 접근 방식을 취했습니다. 바로 상향식 접근 방식입니다.

먼저, 허가 없이 해시레이트 모으기 위해 탈중앙화 형 Prover 네트워크를 구축했습니다. 그런 다음 Prover 네트워크에 Sequencer를 추가하는 방안을 모색했습니다. 이를 위해서는 Prover 네트워크, 특히 성숙한 탈중앙화 네트워크와의 긴밀한 통합이 필요합니다. 이는 추가적인 증명 수수료와 통신 복잡성을 수반하므로, Sequencer는 Prover 네트워크와 긴밀하게 통합되어야 효율성을 보장할 수 있습니다. 저희가 개발한 시스템은 ZK Rollup의 기반 인프라 역할을 할 수 있습니다.

모든 증명 생성이 완료 속도 향상, 품질 향상, 그리고 보안 유지를 위한 인센티브를 제공받을 수 있도록, 모든 증명의 생성 및 순서 관리하는 증명 시장을 도입했습니다. 동시에, 이 시스템의 탈중앙화 되고 허가가 필요 없는 특성을 유지합니다. 이러한 접근 방식은 하향식이 아닌 상향식으로 문제를 해결합니다.

[브라이언 R]

저희의 접근 방식은 다른 네트워크들과 상당히 다르다고 생각합니다. Nil 팀이 구축하고 있는 증명 시장과 유사하지만, 저희는 더 신뢰가 필요 없는 접근 방식을 취하고 있습니다. 시퀀싱에 집중하는 대신, 다양한 계산에 대해 증명 시스템을 더욱 견고하게 만드는 데 집중하고 있습니다. 이러한 접근 방식은 복잡성을 크게 줄이고 최대한 많은 계산을 시장에 최대한 빨리 출시할 수 있도록 도와줍니다.

우리는 개발자들의 진입 장벽을 낮추어 그들이 이더 이나 다른 시스템에서 원하는 애플리케이션을 구축할 수 있도록 하고, 계산의 정확성을 보장하기 위해 제로 지식 증명을 갖춘 탈중앙화 기본 컴퓨팅 계층을 갖고 싶습니다.

그림

Q5. 대상: 알고랜드에는 상태 페인팅(State Painting)이라는 기술이 있습니다. 이 기술의 기본 아이디어는 한 합의 블록체인에서 상태를 클레임 다른 블록 온체인"페인트"하는 것입니다. 이 기술은 영지식 증명을 활용하는 크로스 체인 솔루션에 가깝습니다. 레이어 2에서 시스템 합의는 레이어 1 합의에 의존합니다. 이 방식이 레이어 2 보안을 저해하는가요?

[알렉스 글루코프스키]

ZK 롤업 구현 시, 레이어 1과 레이어 2 간의 자산 흐름은 완전히 신뢰할 필요가 없으며, 레이어 2는 레이어 1의 보안을 상속받습니다. 레이어 2 간의 자산 전송 또한 이더 의 레이어 1 네이티브 브리지를 통해 수행되는 경우 완전히 신뢰할 필요가 없습니다. 그러나 레이어 1을 통해 수행되지 않을 경우, 전송의 보안은 브리지 구현에 사용된 크로스체인 방식에 따라 달라집니다.

zkSync에서는 하이퍼체인(Hyperchain)이라는 것을 구현하고 있습니다. 구체적으로, 이더 이더 기반 브릿지로 연결된 동일한 회로로 구동되는 여러 체인을 구축할 것입니다. 하이퍼체인은 모든 체인에서 다른 체인으로의 무료, 완전 무신뢰, 매우 저렴한 거래를 제공합니다. 수억 명, 심지어 수십억 명의 사용자를 블록체인으로 끌어들이는 데 있어 이는 매우 중요합니다.

미래에는 수조 개의 거래를 단일 시스템이나 합의 알고리즘에서 처리하는 것이 불가능해질 것입니다. 샤딩, 독립 애플리케이션 체인 등 다양한 합의 알고리즘을 사용해야 할 것입니다. 동시에, 이러한 다양한 체인 간의 연결성과 저비용 통신을 보장해야 합니다.

예를 들어, 오늘날 우리가 이메일 시스템을 사용하는 방식과 마찬가지로, 사용자들은 다양한 이메일 시스템을 통해 쉽게 소통할 수 있습니다. 이것이 바로 Hyperchain을 통해 이루고자 하는 바입니다. Hyperchain은 레이어 1의 보안을 완벽하게 계승하고, 효율적이고 신뢰할 수 있는 크로스체인 통신을 제공할 뿐만 아니라, 재귀적 증명을 통해 초저비용을 달성할 수 있습니다.

출처
면책조항: 상기 내용은 작자의 개인적인 의견입니다. 따라서 이는 Followin의 입장과 무관하며 Followin과 관련된 어떠한 투자 제안도 구성하지 않습니다.
라이크
즐겨찾기에 추가
코멘트