Vitalik: 효율성 향상을 위한 새로운 아이디어 - 글루잉 및 코프로세서 아키텍처

원제: Glue와 코프로세서 아키텍처

저자: Vitalik, Ether 창립자, Deng Tong, Golden Finance 편집

특별한 감사를 드리는 분들: Justin Drake, Georgios Konstantopoulos, Andrej Karpathy, Michael Gao, 타룬 치트라, 그리고 피드백과 의견을 제공해 주신 다양한 플래시봇 기여자들에게 감사드립니다.

현대 세계에서 진행되는 리소스 집약적인 연산을 적당한 수준으로 자세히 분석해 보면, 계속해서 발견할 수 있는 특징 중 하나는 연산을 두 부분으로 나눌 수 있다는 점입니다.

• 비교적 적은 양의 복잡하지만 계산 집약적이지 않은 '비즈니스 로직';

• 대량의 계산 집약적이지만 고도로 구조화된 '고비용 작업'.

이 두 가지 형태의 계산은 다르게 처리하는 것이 가장 좋습니다. 전자의 경우 아키텍처의 효율성은 떨어지지만 매우 다재다능해야 하고, 후자의 경우 아키텍처의 다재다능성은 떨어지지만 매우 효율적이어야 합니다.

실제 이러한 다른 접근 방식의 예로는 어떤 것이 있을까요?

먼저 저에게 가장 익숙한 환경인 이더넷 가상 머신(EVM)을 살펴봅시다. 다음은 최근에 수행한 이더넷 트랜잭션의 geth 디버그 트레이스입니다. ENS에서 제 블로그의 IPFS 해시를 업데이트하는 작업입니다. 이 트랜잭션은 총 46,924개의 가스를 소비했으며, 다음과 같이 분류할 수 있습니다.

• 기본 비용: 21,000

• 호출 데이터: 1. ,556

• EVM 실행: 24,368

• SLOAD Opcode: 6,400

• SSTORE opcode: 10,100

• LOG opcode: 2,149

• 기타: 6,719

< span style="font-size: 14px;">ENS 해시 업데이트에 대한 EVM 추적입니다. 두 번째 열은 가스 소비량입니다.

이 이야기의 교훈은 실행의 대부분(EVM만 보면 약 73%, 계산을 포함하는 기본 비용 부분을 포함하면 약 85%)이 스토리지 읽기, 쓰기, 로깅, 암호화 등 매우 적은 수의 구조화되고 비용이 많이 드는 작업에 집중된다는 것입니다(기본 비용에는 서명 검증에 대한 비용 3,000과 해싱에 대한 비용 272가 포함되어 있습니다). 나머지 실행은 "비즈니스 로직"으로, 설정하려는 레코드의 ID와 설정할 해시를 추출하기 위해 호출 데이터의 비트를 교환하는 등의 작업을 수행합니다. 토큰 전송에서는 잔액 더하기와 빼기, 고급 애플리케이션에서는 루프 등이 여기에 포함될 수 있습니다.

EVM에서는 이 두 가지 형태의 실행이 서로 다른 방식으로 처리됩니다. 고수준 비즈니스 로직은 상위 레벨 언어(일반적으로 솔리디티)로 작성되어 EVM으로 컴파일되며, 고비용 작업은 여전히 EVM 옵코드(SLOAD 등)에 의해 트리거되지만 실제 계산의 99% 이상은 클라이언트 측 코드(또는 라이브러리) 내부에서 직접 작성된 특수한 모듈에서 수행됩니다.

이 패턴에 대한 이해를 높이기 위해 다른 맥락, 즉 토치를 사용하여 파이썬으로 작성된 AI 코드를 살펴봅시다.

이미지 src="https://img.jinse.cn/7290598_watermarknone.png" title="7290598" alt="pLGF8omDmigyKSG9Holtr0YEeXlqkEiqjW833sdP.jpeg">

변압기 모델 블록의 포워드 패스

여기에서 무엇을 볼 수 있을까요? 수행 중인 작업의 구조를 설명하는 비교적 적은 양의 "비즈니스 로직"이 파이썬으로 작성된 것을 볼 수 있습니다. 실제로는 입력을 가져오는 방법과 출력에 대해 수행되는 작업과 같은 세부 사항을 결정하는 또 다른 유형의 비즈니스 로직이 있습니다. 그러나 각각의 개별 연산 자체(self.norm, torch.cat, +, *, self.attn ...... 내의 개별 단계)를 자세히 살펴보면 동일한 연산이 많은 수의 값을 병렬로 계산하는 벡터화된 연산을 볼 수 있습니다. 첫 번째 예와 마찬가지로 계산의 일부는 비즈니스 로직에 사용되고 대부분의 계산은 대규모 구조화된 행렬 및 벡터 연산을 수행하는 데 사용되며, 실제로는 대부분 행렬 곱셈에 불과합니다.

EVM 예제에서와 같이 이 두 가지 유형의 작업은 두 가지 방식으로 처리됩니다. 높은 수준의 비즈니스 로직 코드는 매우 범용적이고 유연한 언어인 Python으로 작성되지만 매우 느리고 전체 계산 비용의 일부만 차지하기 때문에 비효율성을 감수하고 있습니다. 한편, 집약적인 작업은 고도로 최적화된 코드, 일반적으로 GPU에서 실행되는 CUDA 코드로 작성됩니다. 점점 더 많은 경우, LLM 추론이 ASIC에서 수행되기 시작하고 있습니다.

SNARK와 같은 최신 프로그래머블 암호화도 두 가지 수준에서 비슷한 패턴을 따릅니다. 첫째, 위의 AI 예시에서처럼 벡터화된 연산을 통해 무거운 작업을 수행하는 고급 언어로 증명자를 작성할 수 있습니다. 여기에 있는 순환형 STARK 코드가 이를 보여줍니다. 둘째, 암호화 내에서 실행되는 프로그램 자체를 범용 비즈니스 로직과 고도로 구조화되고 비용이 많이 드는 작업으로 구분하는 방식으로 작성할 수 있습니다.

이것이 어떻게 작동하는지 알아보기 위해 STARK가 보여주는 최신 트렌드 중 하나를 살펴볼 수 있습니다. 범용적이고 사용하기 쉽도록 하기 위한 노력의 일환으로 RISC-V와 같이 널리 채택된 최소 가상 머신을 위한 STARK 프로바이더를 구축하는 팀이 점점 더 많아지고 있습니다. 실행을 증명해야 하는 모든 프로그램은 RISC-V로 컴파일할 수 있으며, 증명자는 해당 코드의 RISC-V 실행을 증명할 수 있습니다.

RiscZero 문서의 다이어그램

이 방법은 매우 편리합니다. 증명 로직을 한 번만 작성하면 그 이후부터는 증명이 필요한 모든 프로그램이 "전통적인" 증명 로직을 사용할 수 있다는 뜻이죠. 그 이후부터는 증명이 필요한 모든 프로그램을 '전통적인' 프로그래밍 언어로 작성할 수 있습니다(예: RiskZero는 Rust를 지원합니다). 하지만 이 접근 방식에는 많은 오버헤드가 발생한다는 문제가 있습니다. 프로그래밍 가능한 암호화는 이미 매우 비싸고, RISC-V 인터프리터에서 코드를 실행하는 데 추가되는 오버헤드는 너무 많습니다. 그래서 개발자들은 계산의 대부분을 차지하는 특정 고비용 연산(일반적으로 해시 및 서명)을 식별한 다음, 해당 연산을 매우 효율적으로 증명할 수 있는 특수 모듈을 만드는 방법을 생각해 냈습니다. 그런 다음 비효율적이지만 일반적인 RISC-V 증명 시스템과 효율적이지만 특수화된 증명 시스템을 결합하면 두 가지 장점을 모두 얻을 수 있습니다.

다자간 계산(MPC) 및 완전 동형 암호화(FHE) 등 ZK-SNARK 이외의 프로그래밍 가능한 암호화도 유사한 접근 방식을 사용하여 최적화할 수 있습니다.

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

현대 컴퓨팅은 고도로 일반화되어 있지만 비효율적인 중앙 '글루' 구성요소가 있고, 이 구성요소는 덜 일반화되어 있지만 더 효율적인 하나 이상의 코프로세서 구성요소 간에 데이터 전송을 담당하는 글루 및 코프로세서 아키텍처를 점점 더 많이 따르고 있습니다.

이미지 src="https://img.jinse.cn/7290600_watermarknone.png" title="7290600" alt="abhGUxtZnxYpz5SurIDkzwKHbrWsETbobFSspMFw.jpeg">

이것은 단순화입니다. 실제로 효율성과 범용성 사이의 트레이드오프 곡선에는 거의 항상 두 가지 이상의 수준이 있으며, 업계에서 일반적으로 "코프로세서"라고 부르는 GPU 및 기타 칩은 CPU보다는 덜 범용적이지만 ASIC보다는 더 범용적입니다. 전문화의 절충은 복잡하며, 알고리즘의 어떤 부분이 5년 후에도 동일하게 유지되고 어떤 부분이 6개월 후에 변경될지에 대한 예측과 직관에 따라 달라집니다. ZK 증명 아키텍처에서도 이와 유사한 다층적 전문화를 종종 볼 수 있습니다. 그러나 광범위한 사고 모델의 경우 두 가지 계층을 고려하는 것으로 충분합니다. 컴퓨팅의 많은 영역에서 유사점이 있습니다:

위 예시를 보면 계산을 이런 식으로 분할할 수 있다는 것은 분명 자연법칙처럼 보입니다. 실제로 수십 년 동안 계산을 전문화한 사례를 찾아볼 수 있습니다. 하지만 이러한 분리가 점점 더 늘어나고 있다고 생각합니다. 여기에는 이유가 있다고 생각합니다.

우리는 최근에야 CPU 클럭 속도 증가의 한계에 도달했기 때문에 병렬화를 통해서만 더 많은 이득을 얻을 수 있습니다. 그러나 병렬화는 추론하기 어렵기 때문에 개발자는 순차적으로 추론하고 병렬화는 백엔드에서 특정 작업을 위해 구축된 전용 모듈로 감싸는 것이 더 실용적인 경우가 많습니다.

컴퓨팅 속도가 너무 빨라져 비즈니스 로직의 계산 비용이 무시할 수 있을 정도로 낮아진 것은 최근의 일입니다. 이러한 환경에서는 계산 효율성 이외의 목표, 즉 개발자 친화성, 친숙성, 보안 등의 목표를 달성하기 위해 비즈니스 로직이 실행되는 가상 머신을 최적화하는 것이 합리적입니다. 동시에 전용 '코프로세서' 모듈은 효율성을 위해 계속 설계할 수 있으며 바인더를 사용한 비교적 단순한 '인터페이스'를 통해 보안과 개발자 친화성을 확보할 수 있습니다.

가장 중요한 고비용 연산이 무엇인지 명확해지고 있습니다. 이는 모듈로 산술, 타원 곡선의 선형 조합(일명 다중 스칼라 곱셈), 고속 푸리에 변환 등 특정 유형의 고비용 연산이 가장 많이 사용되는 암호화에서 가장 분명하게 드러납니다. 이러한 경향은 20년 이상 대부분의 계산이 "대부분 행렬 곱셈"(정밀도는 다양하지만)인 인공 지능에서도 점점 더 뚜렷해지고 있습니다. 다른 분야에서도 비슷한 추세가 관찰되고 있습니다. (계산 집약적인) 계산에서 미지의 영역은 20년 전에 비해 훨씬 줄어들었습니다.

이것은 무엇을 의미할까요?

한 가지 핵심은 글루어는 좋은 글루어가 되도록 최적화되어야 하고, 코프로세서는 좋은 코프로세서가 되도록 최적화되어야 한다는 것입니다. 이에 대한 함의를 살펴볼 수 있는 몇 가지 주요 영역이 있습니다.

EVM

블록체인 가상머신(예: EVM)은 효율적일 필요는 없고, 친숙할 필요가 있습니다. 적절한 코프로세서(일명 "사전 컴파일")를 추가하면 비효율적인 가상 머신의 연산이 실제로는 기본적으로 효율적인 가상 머신의 연산만큼 효율적일 수 있습니다. 예를 들어, EVM의 256비트 레지스터는 상대적으로 오버헤드가 거의 발생하지 않으며, EVM의 친숙함과 기존 개발자 에코시스템의 이점은 상당하고 오래 지속됩니다. 심지어 EVM을 최적화하는 개발 팀은 병렬 처리 부족이 확장성에 큰 장애가 되지 않는다는 사실을 발견하기도 했습니다.

EVM을 개선하는 가장 좋은 방법은 (i) 더 나은 사전 컴파일 또는 전용 오코드를 추가하는 것(예: EVM-MAX와 SIMD의 일부 조합이 적합할 수 있음)과 (ii) 스토리지 레이아웃을 개선하는 것(예: 버클 트리의 변경으로 서로 인접한 스토리지 슬롯에 액세스하는 비용을 크게 줄이는 것)이 될 수 있습니다.

이더넷 버클 트리 제안의 스토리지 최적화는 인접한 스토리지 키를 함께 배치하고 이를 반영하여 가스 비용을 조정합니다. 이와 같은 최적화는 더 나은 사전 컴파일과 함께 EVM 자체를 조정하는 것보다 더 중요할 수 있습니다.

보안 컴퓨팅과 개방형 하드웨어

하드웨어 수준에서 최신 컴퓨팅의 보안을 개선하는 데 있어 큰 과제 중 하나는 지나치게 복잡하고 독점적인 특성으로, 칩은 고효율로 설계되어 독점적인 최적화를 필요로 한다는 것입니다. 백도어는 쉽게 숨길 수 있으며 사이드 채널 취약점은 지속적으로 발견되고 있습니다.

다양한 각도에서 보다 개방적이고 안전한 대안을 모색하기 위한 노력이 계속되고 있습니다. 일부 컴퓨팅은 사용자의 휴대폰을 비롯한 신뢰할 수 있는 실행 환경에서 점점 더 많이 수행되고 있으며, 이로 인해 사용자 보안이 향상되었습니다. 최근 우분투를 실행하는 RISC-V 노트북과 같이 더 많은 오픈 소스 소비자 하드웨어에 대한 요구가 계속되고 있습니다.

데비안을 실행하는 RISC-V 노트북

그러나 여전히 효율성은 문제입니다. 링크된 글의 작성자는 다음과 같이 썼습니다.

RISC-V와 같은 새로운 오픈 소스 칩 설계는 이미 존재하고 수십 년에 걸쳐 개선된 프로세서 기술과 경쟁할 수 없을 것입니다. 진보에는 항상 출발점이 있습니다.

FPGA에 RISC-V 컴퓨터를 구축하는 이 설계와 같은 보다 편집증적인 아이디어는 더 큰 오버헤드에 직면하게 됩니다. 하지만 글루잉 및 코프로세서 아키텍처를 통해 이러한 오버헤드가 실제로 중요하지 않다면 어떨까요? 개방형 보안 칩이 독점 칩보다 느리고, 필요한 경우 추측 실행 및 분기 예측과 같은 일반적인 최적화를 포기하는 대신 가장 집약적인 특정 유형의 연산을 위해 (필요한 경우 독점) ASIC 모듈을 추가하여 이를 보완하려고 한다면 어떨까요? 민감한 계산은 보안, 오픈 소스 설계 및 사이드 채널 저항에 최적화된 '메인 칩'에서 수행할 수 있습니다. 보다 집약적인 연산(예: ZK 증명, AI)은 수행되는 연산에 대한 정보가 적은(경우에 따라 암호화 블라인딩을 통해 정보가 전혀 없는) ASIC 모듈에서 수행됩니다.

암호화

또 다른 핵심 포인트는 이 모든 것이 암호화, 특히 프로그래밍 가능한 암호화가 주류가 될 것이라는 매우 낙관적인 전망이라는 것입니다. 특정 해시 함수의 오버헤드는 직접 연산을 실행하는 것보다 수백 배에 불과하고 인공물(주로 행렬 곱셈)의 오버헤드는 매우 낮습니다. GKR과 같은 추가 개선으로 이를 더욱 줄일 수 있습니다. 완전히 범용적인 VM 실행, 특히 RISC-V 인터프리터에서 실행할 경우 약 10,000배의 오버헤드가 계속 발생할 수 있지만 이 백서에서 설명한 이유 때문에 이는 중요하지 않습니다. 계산의 가장 집중적인 부분을 효율적인 특수 기술을 사용하여 개별적으로 처리하는 한 총 오버헤드는 관리할 수 있는 수준입니다.

AI 모델 추론에서 가장 큰 구성 요소인 행렬 곱셈 관련 MPC의 단순화된 다이어그램입니다. 모델과 입력을 비공개로 유지하는 방법 등 자세한 내용은 이 문서를 참조하세요.

글루 레이어가 효율적이지 않고 익숙하기만 하면 된다는 생각에 대한 한 가지 예외는 지연 시간과 데이터 대역폭입니다. 암호화와 AI의 경우처럼 동일한 데이터에 대해 수십 번 반복되는 무거운 연산을 계산하는 경우, 비효율적인 글루 레이어로 인한 지연 시간은 런타임에 큰 병목 현상이 될 수 있습니다. 따라서 글루 레이어에도 효율성 요구 사항이 있지만 좀 더 구체적입니다.

결론

전반적으로 위의 트렌드는 여러 관점에서 매우 긍정적인 발전이라고 생각합니다. 무엇보다도 개발자 친화성을 유지하면서 계산 효율성을 극대화할 수 있는 합리적인 방법이며, 두 가지를 동시에 더 많이 얻을 수 있다는 것은 모두에게 좋은 일입니다. 둘째, 효율성 추구가 다른 가치, 특히 보안, 개방성, 단순성을 훼손하지 않도록 컴퓨터 하드웨어의 사이드 채널 보안과 개방성을 보장할 수 있는 큰 기회를 창출합니다, ZK-SNARK의 회로 복잡성 감소, 가상 머신의 복잡성 감소 등입니다. 역사적으로 효율성을 추구하다 보니 이러한 다른 요소들은 뒷전으로 밀려났습니다. 하지만 글루잉 및 코프로세서 아키텍처를 사용하면 더 이상 그럴 필요가 없습니다. 머신의 한 부분은 효율성을 위해 최적화하고, 다른 부분은 범용성 및 기타 가치를 위해 최적화하며, 이 두 가지가 함께 작동합니다.

이러한 추세는 그 자체로 '고비용 구조화 연산'의 대표적인 예인 암호화에도 매우 유리하며, 이러한 추세는 이러한 추세를 가속화합니다. 이는 보안을 개선할 수 있는 또 다른 기회를 추가합니다. 블록체인 세계에서는 보안 개선도 가능합니다. 가상 머신 최적화에 대한 걱정을 덜고 가상 머신과 공존하는 사전 컴파일 및 기타 기능을 최적화하는 데 더 집중할 수 있습니다.

셋째, 이러한 추세는 소규모의 새로운 플레이어가 참여할 수 있는 기회를 제공합니다. 컴퓨팅이 덜 모놀리식화되고 모듈화되면 진입 장벽이 크게 낮아질 것입니다. 한 가지 유형의 컴퓨팅을 사용하는 ASIC도 차이를 만들 수 있는 잠재력을 가지고 있습니다. 이는 ZK 증명 및 EVM 최적화 분야에서도 마찬가지입니다. 거의 프론티어 수준의 효율성으로 코드를 작성하는 것이 더 쉽고 접근하기 쉬워집니다. 이러한 코드에 대한 감사 및 공식적인 검증도 더 쉽고 접근하기 쉬워집니다. 마지막으로, 이처럼 매우 다른 컴퓨팅 영역이 몇 가지 공통된 패턴으로 수렴함에 따라 서로 협력하고 배울 수 있는 여지가 더 많아졌습니다.