Vitalik의 새로운 글: 접착 및 협처리기 아키텍처, 효율성과 안전성을 향상시키는 새로운 구상

원문 제목：《Glue and coprocessor architectures》

저자：Vitalik Buterin, 이더리움 창립자

편집：덩통, 금색 재정

특별히 Justin Drake, Georgios Konstantopoulos, Andrej Karpathy, Michael Gao, Tarun Chitra 및 다양한 Flashbots 기여자들의 피드백과 댓글에 감사드립니다.

현대 세계에서 진행 중인 자원 집약적인 계산을 중간 정도의 세부 사항으로 분석하면, 반복적으로 발견되는 한 가지 특징은 계산이 두 부분으로 나눌 수 있다는 것입니다:

• 상대적으로 적은 양의 복잡하지만 계산량이 적은 「비즈니스 로직」；
• 대량의 밀집하지만 고도로 구조화된 「비용이 많이 드는 작업」.

이 두 가지 계산 형태는 서로 다른 방식으로 처리하는 것이 가장 좋습니다: 전자는 아키텍처가 비효율적일 수 있지만 매우 높은 범용성을 가져야 하고; 후자는 아키텍처가 낮은 범용성을 가질 수 있지만 매우 높은 효율성을 가져야 합니다.

실제에서 이러한 다른 방식의 예는 무엇인가요?

먼저, 제가 가장 잘 아는 환경인 이더리움 가상 머신 (EVM)을 살펴보겠습니다. 이는 제가 최근에 이더리움 거래를 위해 수행한 geth 디버깅 추적입니다: ENS에서 제 블로그의 IPFS 해시를 업데이트한 것입니다. 이 거래는 총 46924 gas를 소모했으며, 다음과 같이 분류할 수 있습니다:

• 기본 비용：21,000
• 호출 데이터：1,556
• EVM 실행：24,368
• SLOAD 연산 코드：6,400
• SSTORE 연산 코드：10,100
• LOG 연산 코드：2,149
• 기타：6,719

ENS 해시 업데이트의 EVM 추적. 끝에서 두 번째 열은 gas 소비입니다.

이 이야기의 교훈은: 대부분의 실행(순수 EVM만 보면 약 73%, 기본 비용 부분을 포함하면 약 85%)이 극소수의 구조화된 비싼 작업에 집중되어 있다는 것입니다: 저장소 읽기 및 쓰기, 로그 및 암호화(기본 비용에는 서명 검증을 위한 3000이 포함되며, EVM은 해시를 지불하기 위해 272를 포함합니다). 나머지 실행은 「비즈니스 로직」입니다: 제가 설정하려는 기록의 ID와 제가 설정한 해시를 추출하기 위해 calldata의 비트를 교환하는 것 등입니다. 토큰 전송에서는 잔액을 더하고 빼는 것이 포함되며, 더 고급 애플리케이션에서는 루프 등이 포함될 수 있습니다.

EVM에서는 이 두 가지 실행 형태가 서로 다른 방식으로 처리됩니다. 고급 비즈니스 로직은 일반적으로 EVM에 컴파일할 수 있는 Solidity와 같은 더 고급 언어로 작성됩니다. 비싼 작업은 여전히 EVM 연산 코드(SLOAD 등)에 의해 트리거되지만, 실제 계산의 99% 이상은 클라이언트 코드(심지어 라이브러리) 내부에 작성된 전용 모듈에서 수행됩니다.

이러한 패턴에 대한 이해를 강화하기 위해, 다른 맥락에서 탐구해 보겠습니다: torch를 사용하여 python으로 작성된 AI 코드입니다.

변압기 모델의 한 블록의 전방 전달

여기서 우리는 무엇을 보고 있습니까? 우리는 실행되고 있는 작업의 구조를 설명하는 상대적으로 적은 양의 「비즈니스 로직」을 보고 있습니다. 실제 애플리케이션에서는 입력을 가져오는 방법 및 출력에 대해 수행할 작업과 같은 세부 사항을 결정하는 또 다른 유형의 비즈니스 로직이 있을 것입니다. 그러나 각 개별 작업 자체(self.norm, torch.cat, +, *, self.attn 내부의 각 단계…)를 깊이 살펴보면, 우리는 벡터화된 계산을 보게 됩니다: 동일한 작업이 대량의 값을 병렬로 계산합니다. 첫 번째 예와 유사하게, 비즈니스 로직에는 소량의 계산이 사용되고, 대부분의 계산은 대규모 구조화된 행렬 및 벡터 연산을 수행하는 데 사용됩니다 ------ 사실, 대부분은 단순히 행렬 곱셈입니다.

EVM 예제와 마찬가지로, 이 두 가지 유형의 작업은 두 가지 다른 방식으로 처리됩니다. 고급 비즈니스 로직 코드는 Python으로 작성되며, 이는 매우 범용적이고 유연한 언어이지만 매우 느립니다. 우리는 단순히 총 계산 비용의 일부에 불과한 비효율성을 받아들입니다. 동시에, 밀집형 작업은 일반적으로 GPU에서 실행되는 CUDA 코드로 작성된 고도로 최적화된 코드입니다. 우리는 ASIC에서 LLM 추론이 이루어지는 것을 점점 더 많이 보기 시작했습니다.

현대의 프로그래머블 암호학, 예를 들어 SNARK는 두 가지 수준에서 다시 유사한 패턴을 따릅니다. 첫째, 증명자는 고급 언어로 작성될 수 있으며, 여기서 무거운 작업은 위의 AI 예와 같이 벡터화된 작업을 통해 수행됩니다. 제가 여기서 보여주는 원형 STARK 코드는 이를 보여줍니다. 둘째, 암호학 내부에서 실행되는 프로그램 자체는 범용 비즈니스 로직과 고도로 구조화된 비싼 작업 간의 경계를 설정하는 방식으로 작성될 수 있습니다.

작동 방식을 이해하기 위해, STARK 증명의 최신 트렌드 중 하나를 살펴보겠습니다. 범용적이고 사용하기 쉬운 STARK 증명기를 위해 팀은 점점 더 널리 채택되는 최소 가상 머신(예: RISC-V)을 구축하고 있습니다. 실행 상황을 증명해야 하는 프로그램은 모두 RISC-V로 컴파일될 수 있으며, 그 후 증명자는 해당 코드의 RISC-V 실행 상황을 증명할 수 있습니다.

RiscZero 문서의 차트

이는 매우 편리합니다: 이는 우리가 증명 논리를 한 번만 작성하면, 그 이후로 증명이 필요한 프로그램은 어떤 「전통적인」 프로그래밍 언어로도 작성될 수 있음을 의미합니다(예: RiskZero는 Rust를 지원합니다). 그러나 한 가지 문제가 있습니다: 이 방법은 큰 오버헤드를 발생시킵니다. 프로그래머블 암호화는 이미 매우 비쌉니다; RISC-V 해석기에서 실행 코드를 실행하는 오버헤드를 추가하는 것은 너무 많습니다. 따라서 개발자들은 한 가지 요령을 생각해냈습니다: 대부분의 계산을 구성하는 특정 비싼 작업(일반적으로 해시 및 서명)을 식별한 다음, 이러한 작업을 매우 효율적으로 증명하기 위한 전용 모듈을 생성하는 것입니다. 그런 다음 비효율적이지만 범용적인 RISC-V 증명 시스템과 효율적이지만 전문적인 증명 시스템을 결합하여 두 가지를 모두 만족시킬 수 있습니다.

ZK-SNARK 외의 프로그래머블 암호화, 예를 들어 다자간 계산(MPC) 및 완전 동형 암호(FHE)는 유사한 방법으로 최적화될 수 있습니다.

전반적으로 현상은 어떤가요?

현대 계산은 제가 말하는 접착제 및 보조 프로세서 아키텍처를 점점 더 많이 따릅니다: 중앙의 「접착제」 구성 요소가 있으며, 이는 높은 범용성을 가지지만 비효율적이며, 하나 이상의 보조 프로세서 구성 요소 간에 데이터를 전송하는 역할을 합니다. 이러한 보조 프로세서 구성 요소는 낮은 범용성을 가지지만 효율성이 높습니다.

이는 단순화된 것입니다: 실제로는 효율성과 범용성 간의 균형 곡선이 거의 항상 두 개 이상의 수준을 가지고 있습니다. GPU 및 산업에서 일반적으로 「보조 프로세서」라고 불리는 기타 칩은 CPU보다 범용성이 떨어지지만 ASIC보다 더 범용적입니다. 전문화의 균형은 복잡하며, 이는 알고리즘의 어떤 부분이 5년 후에도 변하지 않을 것인지, 어떤 부분이 6개월 후에 변할 것인지에 대한 예측과 직관에 따라 달라집니다. ZK 증명 아키텍처에서는 유사한 다층 전문화를 자주 볼 수 있습니다. 그러나 광범위한 사고 모델을 고려할 때, 두 가지 수준을 고려하는 것으로 충분합니다. 많은 계산 분야에서 유사한 상황이 있습니다:

위의 예에서 볼 수 있듯이, 계산은 확실히 이러한 방식으로 분할될 수 있으며, 이는 자연의 법칙처럼 보입니다. 사실, 수십 년 동안 계산 전문화의 예를 찾을 수 있습니다. 그러나 저는 이러한 분리가 증가하고 있다고 생각합니다. 그 이유가 있습니다:

우리는 최근에 CPU 클럭 속도의 향상 한계에 도달했기 때문에, 추가 이익을 얻으려면 병렬화만이 유일한 방법입니다. 그러나 병렬화는 추론하기 어렵기 때문에, 개발자에게는 순차적으로 추론하고 병렬화가 백엔드에서 발생하도록 하는 것이 더 실용적이며, 특정 작업을 위해 구축된 전용 모듈에 포장하는 것이 더 쉽습니다.

계산 속도가 최근에 매우 빨라져서 비즈니스 로직의 계산 비용이 실제로 무시할 수 있을 정도가 되었습니다. 이 세계에서는 비즈니스 로직 실행을 최적화하여 계산 효율성 외의 목표를 달성하는 것도 의미가 있습니다: 개발자 친화성, 친숙함, 보안 및 기타 유사한 목표. 동시에, 전용의 「보조 프로세서」 모듈은 효율성을 위해 계속 설계될 수 있으며, 접착제와의 상대적으로 간단한 「인터페이스」에서 보안성과 개발자 친화성을 얻을 수 있습니다.

가장 중요한 비싼 작업이 무엇인지 점점 더 명확해지고 있습니다. 이는 암호학에서 가장 두드러지며, 어떤 특정 비싼 작업 유형이 가장 많이 사용될 가능성이 있는지를 보여줍니다: 모듈 연산, 타원 곡선 선형 조합(다중 스칼라 곱셈이라고도 함), 빠른 푸리에 변환 등입니다. 인공지능에서도 이 상황이 점점 더 뚜렷해지고 있으며, 20년 이상 동안 대부분의 계산이 「주로 행렬 곱셈」이었습니다(정확도 수준은 다르지만). 다른 분야에서도 유사한 경향이 나타나고 있습니다. 20년 전과 비교할 때, (계산 집약적인) 계산에서의 미지수는 훨씬 적습니다.

이것은 무엇을 의미하나요?

핵심 포인트는, 접착제(Glue)는 좋은 접착제가 되도록 최적화되어야 하며, 보조 프로세서(coprocessor)도 좋은 보조 프로세서가 되도록 최적화되어야 한다는 것입니다. 우리는 여러 주요 분야에서 이것이 의미하는 바를 탐구할 수 있습니다.

EVM

블록체인 가상 머신(예: EVM)은 효율적일 필요는 없으며, 익숙하기만 하면 됩니다. 올바른 보조 프로세서(일명 「프리컴파일」)를 추가하기만 하면, 비효율적인 VM의 계산은 실제로 네이티브 효율적인 VM의 계산만큼 효율적일 수 있습니다. 예를 들어, EVM의 256비트 레지스터에서 발생하는 오버헤드는 상대적으로 작으며, EVM의 익숙함과 기존 개발자 생태계가 가져오는 이점은 거대하고 지속적입니다. EVM 최적화 개발팀은 비병렬화의 부족이 일반적으로 확장성의 주요 장애물이 아니라는 것을 발견했습니다.

EVM을 개선하는 가장 좋은 방법은 아마도 (i) EVM-MAX 및 SIMD의 조합과 같은 더 나은 프리컴파일 또는 전용 연산 코드를 추가하는 것과 (ii) 저장소 레이아웃을 개선하는 것일 수 있습니다. 예를 들어, Verkle 트리의 변경은 부작용으로 서로 인접한 저장소 슬롯에 접근하는 비용을 크게 줄입니다.

이더리움 Verkle 트리 제안의 저장소 최적화, 인접한 저장소 키를 함께 배치하고 이를 반영하여 gas 비용을 조정합니다. 이러한 최적화와 더 나은 프리컴파일이 EVM 자체를 조정하는 것보다 더 중요할 수 있습니다.

안전한 계산 및 오픈 하드웨어

하드웨어 수준에서 현대 계산의 안전성을 높이는 주요 도전 과제 중 하나는 그 복잡하고 독점적인 특성입니다: 칩 설계는 효율성을 위해 이루어지며, 이는 독점적인 최적화를 필요로 합니다. 백도어는 쉽게 숨겨질 수 있으며, 사이드 채널 취약점은 지속적으로 발견되고 있습니다.

사람들은 더 개방적이고 안전한 대안을 추진하기 위해 여러 각도에서 노력하고 있습니다. 일부 계산은 점점 더 신뢰할 수 있는 실행 환경에서 수행되며, 이는 사용자의 안전성을 높였습니다. 더 오픈 소스 소비 하드웨어를 추진하는 노력은 계속되고 있으며, 최근에는 Ubuntu를 실행하는 RISC-V 노트북과 같은 몇 가지 승리를 거두었습니다.

Debian을 실행하는 RISC-V 노트북

그러나 효율성은 여전히 문제입니다. 위 링크의 기사를 쓴 저자는 다음과 같이 썼습니다:

RISC-V와 같은 최신 오픈 소스 칩 설계는 이미 존재하고 수십 년 동안 개선된 프로세서 기술과 경쟁할 수 없습니다. 발전에는 항상 출발점이 있습니다.

더 편집증적인 생각, 예를 들어 FPGA에서 RISC-V 컴퓨터를 구축하는 설계는 더 큰 오버헤드에 직면해 있습니다. 그러나 만약 접착제와 보조 프로세서 아키텍처가 이러한 오버헤드가 실제로 중요하지 않다는 것을 의미한다면 어떻게 될까요? 만약 우리가 개방적이고 안전한 칩이 독점 칩보다 느릴 것이라는 것을 받아들이고, 필요하다면 추측 실행 및 분기 예측과 같은 일반적인 최적화를 포기하더라도, 가장 밀집된 특정 유형의 계산을 위해 (필요하다면 독점적인) ASIC 모듈을 추가하여 이를 보완하려고 한다면 어떻게 될까요? 민감한 계산은 「주 칩」에서 수행될 수 있으며, 이 칩은 보안성, 오픈 소스 설계 및 사이드 채널 저항을 위해 최적화될 것입니다. 더 밀집된 계산(예: ZK 증명, AI)은 ASIC 모듈에서 수행되며, 이는 실행되고 있는 계산에 대한 정보가 더 적을 것입니다(어떤 경우에는 암호화된 블라인딩을 통해 심지어 제로 정보일 수도 있습니다).

암호학

또 다른 핵심 포인트는, 이 모든 것이 암호학, 특히 프로그래머블 암호학이 주류가 되는 것에 대해 매우 낙관적이라는 것입니다. 우리는 이미 SNARK, MPC 및 기타 설정에서 특정 고도로 구조화된 계산의 초최적화 구현을 보았습니다: 특정 해시 함수의 오버헤드는 직접 계산을 실행하는 것보다 몇 백 배 비쌀 뿐이며, 인공지능(주로 행렬 곱셈)의 오버헤드도 매우 낮습니다. GKR와 같은 추가 개선은 이 수준을 더욱 낮출 수 있습니다. 완전히 범용적인 VM 실행, 특히 RISC-V 해석기에서 실행할 때, 여전히 약 10,000배의 오버헤드를 발생시킬 수 있지만, 본문에서 설명한 이유로 이는 중요하지 않습니다: 계산에서 가장 밀집된 부분을 각각 효율적인 전용 기술로 처리하기만 하면 총 오버헤드는 통제 가능하게 됩니다.

AI 모델 추론에서 가장 큰 구성 요소인 행렬 곱셈 전용 MPC의 간소화된 도표입니다. 모델과 입력의 비밀을 유지하는 방법에 대한 자세한 내용은 본문을 참조하십시오.

「접착제 층은 익숙하기만 하면 되고, 효율적일 필요는 없다」는 생각의 한 가지 예외는 지연과 데이터 대역폭의 경우입니다. 만약 계산이 동일한 데이터에 대해 수십 번 반복되는 무거운 작업을 포함한다면(암호학 및 인공지능과 같이), 비효율적인 접착제 층으로 인해 발생하는 지연은 실행 시간의 주요 병목이 될 수 있습니다. 따라서 접착제 층에도 효율성 요구 사항이 있으며, 비록 이러한 요구 사항이 더 구체적일지라도 말입니다.

결론

전반적으로, 저는 위의 추세가 여러 각도에서 매우 긍정적인 발전이라고 생각합니다. 첫째, 이는 개발자 친화성을 유지하면서 계산 효율성을 극대화하는 합리적인 방법으로, 모든 사람에게 더 많은 혜택을 제공할 수 있습니다. 특히, 클라이언트에서 전문화를 구현하여 효율성을 높임으로써, 우리는 사용자 하드웨어에서 민감하고 성능 요구가 높은 계산(예: ZK 증명, LLM 추론)을 실행할 수 있는 능력을 향상시킵니다. 둘째, 이는 효율성 추구가 보안성, 개방성 및 단순성과 같은 다른 가치에 해를 끼치지 않도록 보장하는 거대한 기회를 창출합니다: 컴퓨터 하드웨어의 사이드 채널 보안 및 개방성, ZK-SNARK에서 회로 복잡성 감소 및 가상 머신 내 복잡성 감소. 역사적으로, 효율성 추구는 이러한 다른 요소들이 부차적인 위치에 놓이게 했습니다. 접착제와 보조 프로세서 아키텍처가 있으면 더 이상 필요하지 않습니다. 기계의 일부는 효율성을 최적화하고, 다른 부분은 범용성과 기타 가치를 최적화하며, 두 가지가 협력하여 작동합니다.

이러한 추세는 암호학에도 매우 유리합니다. 왜냐하면 암호학 자체가 「비싼 구조화된 계산」의 주요 예시이기 때문이며, 이 추세는 이러한 추세의 발전을 가속화하고 있습니다. 이는 보안성을 높일 수 있는 또 다른 기회를 추가합니다. 블록체인 세계에서 보안성 향상도 가능해졌습니다: 우리는 가상 머신의 최적화에 대해 덜 걱정하고, 프리컴파일 및 가상 머신과 공존하는 다른 기능의 최적화에 더 집중할 수 있습니다.

셋째, 이 추세는 규모가 작고 새로운 참여자에게 참여할 기회를 제공합니다. 만약 계산이 덜 단일화되고 더 모듈화된다면, 이는 진입 장벽을 크게 낮출 것입니다. 동일한 유형의 계산을 위한 ASIC을 사용하더라도, 의미 있는 기여를 할 수 있습니다. ZK 증명 분야와 EVM 최적화에서도 마찬가지입니다. 거의 최첨단 수준의 효율성을 가진 코드를 작성하는 것이 더 쉬워지고 접근 가능해집니다. 이러한 코드의 감사 및 형식적 검증이 더 쉬워지고 접근 가능해집니다. 마지막으로, 이러한 매우 다른 계산 분야가 몇 가지 공통 패턴으로 수렴하고 있기 때문에, 이들 간의 협력과 학습 공간이 더 많아지고 있습니다.