원제: Glue 및 보조 프로세서 아키텍처
원저자: 이더리움 창시자 Vitalik Buterin
원본 편집: Deng Tong, Golden Finance
피드백과 의견을 주신 Justin Drake, Georgios Konstantopoulos, Andrej Karpathy, Michael Gao, Tarun Chitra 및 다양한 Flashbots 기고자에게 특별히 감사드립니다.
현대 사회에서 진행되는 리소스 집약적인 계산을 어느 정도 자세히 분석하면, 계속해서 발견할 수 있는 특징 중 하나는 계산이 두 부분으로 나눌 수 있다는 것입니다.
· 상대적으로 적은 양의 복잡하지만 계산 집약적인 비즈니스 로직;
· 집약적이지만 고도로 구조화된 비용이 많이 드는 작업이 많습니다.
이 두 가지 형태의 컴퓨팅은 서로 다른 방식으로 처리하는 것이 가장 좋습니다. 전자는 아키텍처가 덜 효율적이지만 매우 일반적이어야 하며, 후자는 아키텍처가 덜 일반적이지만 매우 효율적이어야 합니다.
실제로 이러한 다양한 접근 방식의 예는 무엇입니까?
먼저, 나에게 가장 친숙한 환경인 EVM(Ethereum Virtual Machine)을 살펴보겠습니다. 다음은 제가 최근 수행한 Ethereum 트랜잭션의 geth 디버그 추적입니다. ENS에서 내 블로그의 IPFS 해시 업데이트. 이 거래는 총 46924 가스를 소비했으며 다음과 같이 분류할 수 있습니다.
· 기본 비용 : 21,000
· 통화 데이터: 1,556 EVM
· 실행 : 24, 368 SLOAD
· 연산코드: 6, 400 SSTORE
· 연산코드: 10, 100 LOG
· 연산코드: 2, 149
· 기타 : 6,719
ENS 해시 업데이트의 EVM 추적. 두 번째 열은 가스 소비량입니다.
이야기의 교훈은 다음과 같습니다. 실행의 대부분(EVM만 보면 약 73%, 계산을 포함하는 기본 비용 부분을 포함하면 약 85%)이 매우 소수의 구조화된 고비용 작업인 스토리지 읽기에 집중되어 있습니다. 쓰기, 로깅 및 암호화(기본 비용에는 결제 서명 확인을 위한 3000이 포함되고, EVM에는 결제 해싱을 위한 272도 포함됩니다). 나머지 실행은 비즈니스 로직입니다. calldata의 비트를 교환하여 설정하려는 레코드의 ID, 설정하려는 해시 등을 추출합니다. 토큰 전송에서 여기에는 잔액 추가 및 빼기가 포함되며, 고급 애플리케이션에서는 회전 등이 포함될 수 있습니다.
EVM에서는 이 두 가지 실행 형태가 다르게 처리됩니다. 높은 수준의 비즈니스 로직은 일반적으로 EVM으로 컴파일되는 더 높은 수준의 언어인 Solidity로 작성됩니다. 비용이 많이 드는 작업은 여전히 EVM opcode(SLOAD 등)에 의해 실행되지만 실제 계산의 99% 이상이 클라이언트 코드(또는 라이브러리) 내부에 직접 작성된 전용 모듈에서 수행됩니다.
이 패턴에 대한 이해를 높이기 위해 다른 맥락에서 살펴보겠습니다. 즉, 토치를 사용하여 Python으로 작성된 AI 코드입니다.
변압기 모델 블록의 순방향 통과
여기서 무엇을 볼 수 있나요? 우리는 수행되는 작업의 구조를 설명하는 Python으로 작성된 비교적 적은 양의 비즈니스 로직을 보았습니다. 실제 애플리케이션에는 입력을 얻는 방법 및 출력으로 수행할 작업과 같은 세부 사항을 결정하는 또 다른 유형의 비즈니스 논리가 있습니다. 그러나 각 개별 작업 자체(self.norm, torch.cat, +, *, self.attn... 내부의 개별 단계)를 자세히 살펴보면 벡터화된 계산을 볼 수 있습니다. 동일한 작업이 병렬 값으로 대규모로 계산됩니다. . 첫 번째 예와 유사하게 계산의 작은 부분은 비즈니스 논리에 사용되며 대부분의 계산은 구조화된 대규모 행렬 및 벡터 연산을 수행하는 데 사용됩니다. 실제로 대부분은 행렬 곱셈입니다.
EVM 예와 마찬가지로 이 두 가지 유형의 작업은 두 가지 다른 방식으로 처리됩니다. 높은 수준의 비즈니스 로직 코드는 다재다능하고 유연한 언어인 Python으로 작성되었지만 속도도 매우 느리며 전체 계산 비용의 극히 일부만 차지하므로 비효율성을 받아들일 수 있습니다. 동시에 집약적인 작업은 고도로 최적화된 코드(종종 GPU에서 실행되는 CUDA 코드)로 작성됩니다. 점점 더 ASIC에서 LLM 추론이 수행되는 것을 보기 시작했습니다.
SNARK와 같은 최신 프로그래밍 가능 암호화는 다시 두 가지 수준에서 유사한 패턴을 따릅니다. 첫째, 증명자는 위의 AI 예시처럼 벡터화된 연산을 통해 무거운 작업을 수행하는 고급 언어로 작성될 수 있습니다. 여기에 있는 원형 STARK 코드가 이를 보여줍니다. 둘째, 암호화 내부에서 실행되는 프로그램 자체는 일반 비즈니스 로직과 고도로 구조화된 고비용 작업을 구분하는 방식으로 작성될 수 있습니다.
이것이 어떻게 작동하는지 이해하기 위해 STARK가 보여주는 최신 트렌드 중 하나를 살펴보겠습니다. 다재다능하고 사용하기 쉽도록 팀에서는 RISC-V와 같이 널리 채택되는 최소 가상 머신에 대한 STARK 증명자를 점점 더 많이 구축하고 있습니다. 실행이 입증되어야 하는 모든 프로그램은 RISC-V로 컴파일될 수 있으며, 검증자는 해당 코드의 RISC-V 실행을 입증할 수 있습니다.
RiscZero 문서의 다이어그램
이는 매우 편리합니다. 즉, 증명 논리를 한 번만 작성하면 되며 그 이후로는 증명이 필요한 모든 프로그램을 전통적인 프로그래밍 언어로 작성할 수 있습니다(예: RiskZero는 Rust를 지원함). 그러나 문제가 있습니다. 이 접근 방식은 많은 오버헤드를 발생시킵니다. 프로그래밍 가능한 암호화는 이미 매우 비용이 많이 듭니다. RISC-V 인터프리터에서 코드를 실행하는 데 드는 오버헤드를 추가하는 것은 너무 많습니다. 그래서 개발자들은 계산의 대부분을 구성하는 비용이 많이 드는 특정 작업(일반적으로 해시 및 서명)을 식별한 다음 특수 모듈을 만들어 해당 작업을 매우 효율적으로 증명하는 트릭을 생각해 냈습니다. 그런 다음 비효율적이지만 일반적인 RISC-V 증명 시스템과 효율적이지만 전문화된 증명 시스템을 결합하여 두 가지 장점을 모두 얻을 수 있습니다.
MPC(다자간 계산) 및 FHE(완전 동형 암호화)와 같은 ZK-SNARK 이외의 프로그래밍 가능한 암호화는 유사한 방법을 사용하여 최적화될 수 있습니다.
전반적으로 현상은 어떤가요?
현대 컴퓨팅은 점점 더 제가 글루 및 보조 프로세서 아키텍처라고 부르는 방식을 따르고 있습니다. 하나 이상의 보조 프로세서 구성 요소 사이에서 작업을 실행하는 기능은 매우 다양하지만 비효율적이며 일반성은 낮지만 전송 효율성은 높은 일부 중앙 접착 구성 요소가 있습니다. 그들 사이의 데이터.
이는 단순화된 것입니다. 실제로 효율성과 다양성 사이의 균형 곡선은 거의 항상 두 개 이상의 수준을 갖습니다. 업계에서 일반적으로 코프로세서라고 불리는 GPU 및 기타 칩은 CPU보다 다용도가 떨어지지만 ASIC보다 다용도가 높습니다. 전문화 트레이드오프는 복잡하며 알고리즘의 어떤 부분이 5년 후에 동일하게 유지되고 어떤 부분이 6개월 후에 변경될지에 대한 예측과 직관에 따라 달라집니다. ZK 증명 아키텍처에서는 유사한 여러 전문화 계층을 자주 볼 수 있습니다. 그러나 광범위한 정신 모델의 경우 두 가지 수준을 고려하는 것으로 충분합니다. 컴퓨팅의 여러 영역에도 비슷한 상황이 존재합니다.
위의 예를 보면, 계산이 이렇게 나누어질 수 있다는 것은 확실히 자연법칙처럼 보입니다. 실제로 수십 년에 걸쳐 컴퓨팅 전문화의 예를 찾을 수 있습니다. 그런데 이런 분리가 점점 늘어나고 있는 것 같아요. 나는 이것에 대한 이유가 있다고 생각합니다:
우리는 최근에야 CPU 클럭 속도 향상의 한계에 도달했으므로 병렬화를 통해서만 더 많은 이득을 얻을 수 있습니다. 그러나 병렬화는 추론하기 어렵기 때문에 개발자가 순차적으로 추론을 계속하고 특정 작업을 위해 구축된 특수 모듈로 래핑된 백엔드에서 병렬화가 발생하도록 하는 것이 더 실용적인 경우가 많습니다.
계산 속도는 최근에야 너무 빨라져서 비즈니스 로직의 계산 비용은 정말 무시할 수 있는 수준이 되었습니다. 이 세계에서는 컴퓨팅 효율성 이외의 목표(개발자 친화성, 친숙성, 보안 및 기타 유사한 목표)를 달성하기 위해 비즈니스 논리가 실행되는 VM을 최적화하는 것도 의미가 있습니다. 한편, 전용 코프로세서 모듈은 효율성을 위해 계속 설계될 수 있으며 접착제에 대한 상대적으로 단순한 인터페이스에서 보안 및 개발자 친화성을 이끌어낼 수 있습니다.
가장 중요한 비용이 많이 드는 작업이 무엇인지가 점점 더 명확해지고 있습니다. 이는 모듈러스 연산, 타원 곡선의 선형 조합(다중 스칼라 곱셈), 고속 푸리에 변환 등 특정 유형의 값비싼 연산이 사용될 가능성이 가장 높은 암호화에서 가장 분명합니다. 이는 20년 이상 동안 대부분의 계산이 대부분 행렬 곱셈(정밀도 수준은 다양하지만)이었던 인공 지능에서도 점점 더 분명해지고 있습니다. 다른 분야에서도 비슷한 추세가 나타나고 있습니다. (컴퓨팅 집약적) 컴퓨팅에는 20년 전보다 알려지지 않은 미지의 항목이 훨씬 적습니다.
그게 무슨 뜻이야?
핵심은 글루가 좋은 글루가 되도록 최적화되어야 하고 보조 프로세서가 좋은 보조 프로세서가 되도록 최적화되어야 한다는 것입니다. 우리는 몇 가지 주요 영역에서 이것이 의미하는 바를 탐구할 수 있습니다.
EVM
블록체인 가상 머신(예: EVM)은 효율적일 필요는 없으며 단지 익숙할 뿐입니다. 단순히 올바른 보조 프로세서(사전 컴파일이라고도 함)를 추가하면 비효율적인 VM의 계산이 실제로 기본적으로 효율적인 VM의 계산만큼 효율적일 수 있습니다. 예를 들어, EVM의 256비트 레지스터로 인해 발생하는 오버헤드는 상대적으로 작은 반면, EVM의 친숙성과 기존 개발자 생태계의 이점은 상당하고 오래 지속됩니다. EVM을 최적화하는 개발 팀은 병렬성 부족이 확장성에 대한 주요 장벽이 아닌 경우가 많다는 사실도 발견했습니다.
EVM을 개선하는 가장 좋은 방법은 (i) 더 나은 사전 컴파일 또는 특수 opcode를 추가하는 것일 수 있습니다. 예를 들어 EVM-MAX와 SIMD의 일부 조합은 합리적일 수 있으며 (ii) Verkle 트리와 같은 메모리 레이아웃을 개선하는 것입니다. , 부작용으로 서로 인접한 스토리지 슬롯에 액세스하는 비용이 크게 절감됩니다.
인접한 스토리지 키를 함께 배치하고 이를 반영하기 위해 가스 비용을 조정하는 Ethereum Verkle 트리 제안의 스토리지 최적화입니다. 이와 같은 최적화는 더 나은 사전 컴파일과 결합되어 EVM 자체를 조정하는 것보다 더 중요할 수 있습니다.
보안 컴퓨팅 및 개방형 하드웨어
하드웨어 수준에서 최신 컴퓨팅의 보안을 향상시키는 과제 중 하나는 지나치게 복잡하고 독점적인 특성입니다. 칩은 효율적으로 설계되므로 독점적인 최적화가 필요합니다. 백도어는 숨기기 쉬우며 사이드 채널 취약점은 지속적으로 발견되고 있습니다.
다양한 각도에서 더욱 개방적이고 안전한 대안을 찾기 위한 노력이 계속되고 있습니다. 일부 컴퓨팅은 사용자의 휴대폰을 포함하여 신뢰할 수 있는 실행 환경에서 점점 더 많이 수행되어 사용자 보안이 향상되었습니다. Ubuntu를 실행하는 RISC-V 노트북과 같은 최근의 성공을 통해 더 많은 오픈 소스 소비자 하드웨어에 대한 추진이 계속되고 있습니다.
Debian을 실행하는 RISC-V 노트북
그러나 효율성은 여전히 문제로 남아 있습니다. 위에 링크된 기사의 저자는 다음과 같이 썼습니다.
RISC-V와 같은 최신 오픈 소스 칩 설계는 이미 존재하고 수십 년에 걸쳐 개선된 프로세서 기술과 경쟁할 가능성이 낮습니다. 진보에는 항상 출발점이 있습니다.
FPGA에 RISC-V 컴퓨터를 구축하는 설계와 같은 편집증적인 아이디어는 더 큰 오버헤드에 직면합니다. 그러나 접착 및 보조 프로세서 아키텍처로 인해 이러한 오버헤드가 실제로 중요하지 않다면 어떻게 될까요? 개방형 보안 칩이 독점 칩보다 느리다는 점을 인정한다면 필요한 경우 추측 실행 및 분기 예측과 같은 일반적인 최적화를 포기하지만 대부분의 집중 칩에서 사용되는 (필요한 경우 독점) ASIC 모듈을 추가하여 이를 보상하려고 합니다. 특정 유형의 계산은 어떻습니까? 보안, 오픈 소스 설계 및 부채널 저항에 최적화된 메인 칩에서 민감한 계산을 수행할 수 있습니다. 보다 집중적인 계산(예: ZK 증명, AI)은 ASIC 모듈에서 수행되며 수행되는 계산에 대한 정보가 더 적습니다(암호화 블라인드를 통해 어떤 경우에는 정보가 0일 수도 있음).
암호화
또 다른 핵심 포인트는 이것이 모두 암호화에 대해 매우 낙관적이라는 것입니다. 특히 프로그래밍 가능한 암호화가 주류가 되고 있다는 것입니다. 우리는 SNARK, MPC 및 기타 설정에서 고도로 구조화된 특정 계산의 일부 최적화된 구현을 보았습니다. 일부 해시 함수는 계산을 직접 실행하는 것보다 비용이 수백 배 더 높으며 인공 지능(주로 행렬 곱셈) 오버헤드 또한 매우 낮습니다. GKR과 같은 추가 개선으로 이 수준이 더욱 낮아질 수 있습니다. 완전히 일반적인 VM 실행, 특히 RISC-V 인터프리터에서 실행될 때 계속해서 약 10,000배 더 많은 오버헤드가 발생할 수 있지만 이 문서에 설명된 이유로 인해 이는 중요하지 않습니다. 효율적인 특수 기술을 각각 사용하는 한 가장 계산 집약적인 부품을 처리함으로써 전체 비용을 제어할 수 있습니다.
AI 모델 추론의 가장 큰 구성 요소인 행렬 곱셈 전용 MPC의 단순화된 다이어그램입니다. 모델 및 입력을 비공개로 유지하는 방법을 포함한 자세한 내용은 이 문서를 참조하세요.
접착층은 효율적이지 않고 익숙하기만 하면 된다는 생각에 대한 예외는 대기 시간과 그 정도는 덜하지만 데이터 대역폭입니다. 계산에 동일한 데이터에 대한 과도한 작업이 수십 번 포함되는 경우(암호화 및 인공 지능에서와 같이) 비효율적인 글루 레이어로 인한 지연이 런타임에 주요 병목 현상이 될 수 있습니다. 따라서 글루 라인에도 효율성 요구 사항이 있지만 이러한 요구 사항은 더 구체적입니다.
결론적으로
전반적으로 위의 추세는 여러 측면에서 볼 때 매우 긍정적인 발전이라고 생각합니다. 첫째, 이는 개발자 친화적인 상태를 유지하면서 계산 효율성을 최대화하는 논리적인 방법이며, 두 가지 모두를 더 많이 얻을 수 있다는 것은 모두에게 좋습니다. 특히 효율성을 높이기 위해 클라이언트 측에서 전문화를 활성화함으로써 민감하고 성능이 요구되는 계산(예: ZK 증명, LLM 추론)을 사용자 하드웨어에서 로컬로 실행하는 능력을 향상시킵니다. 둘째, 효율성 추구가 다른 가치, 특히 보안, 개방성 및 단순성을 손상시키지 않도록 보장하는 거대한 기회 창을 생성합니다. 즉, 컴퓨터 하드웨어의 부채널 보안 및 개방성, ZK-SNARK의 회로 복잡성 감소 및 가상 머신의 복잡성. 역사적으로 효율성 추구로 인해 이러한 다른 요소가 뒷전으로 밀렸습니다. 글루와 보조 프로세서 아키텍처를 사용하면 더 이상 필요하지 않습니다. 기계의 한 부분은 효율성을 최적화하고, 다른 부분은 다양성과 기타 가치를 최적화하며, 두 부분이 함께 작동합니다.
이러한 추세는 암호화에도 매우 적합합니다. 암호화 자체는 비싼 구조화 계산의 대표적인 예이며 이러한 추세는 이러한 추세를 가속화합니다. 이는 보안을 향상할 수 있는 또 다른 기회를 추가합니다. 블록체인 세계에서는 보안 향상도 가능합니다. 가상 머신 최적화에 대한 걱정을 덜고 가상 머신과 공존하는 사전 컴파일 및 기타 기능 최적화에 더 집중할 수 있습니다.
셋째, 이러한 추세는 소규모의 신규 플레이어가 참여할 수 있는 기회를 제공합니다. 컴퓨팅이 덜 획일적이고 모듈화되면 진입 장벽이 크게 낮아질 것입니다. 한 가지 유형의 컴퓨팅 ASIC을 사용하더라도 잠재적으로 차이를 만들 수 있습니다. ZK 증명과 EVM 최적화 분야에서도 마찬가지입니다. 최첨단에 가까운 효율성으로 코드를 작성하는 것이 더 쉽고 접근하기 쉬워졌습니다. 이러한 코드를 감사하고 공식적으로 검증하는 것이 더 쉽고 접근하기 쉬워졌습니다. 마지막으로, 매우 다양한 컴퓨팅 영역이 몇 가지 공통 패턴으로 수렴되고 있기 때문에 이들 간의 협업과 학습을 위한 여지가 더 많습니다.
