우리가 블록체인을 사용하는 주된 이유 중 하나는 무신뢰입니다. 이 재산은 우리가 우리의 부와 데이터에 대한 자주적 접근을 허용할 것을 약속합니다. 대부분의 경우 이더리움과 같은 블록체인은 이 약속을 이행했습니다. 우리의 자산은 진정으로 우리의 것입니다.
그러나 편의를 위해 양보한 사항이 있습니다. 그러한 영역 중 하나는 중앙 집중식 RPC(원격 프로시저 호출) 서버를 사용하는 것입니다. 사용자는 일반적으로 Alchemy와 같은 중앙 집중식 공급자를 통해 이더리움에 액세스합니다. 이 회사들은 다른 사람들이 체인 데이터에 쉽게 액세스할 수 있도록 클라우드 서버에서 고성능 노드를 실행합니다. 지갑이 토큰 잔액을 조회하거나 보류 중인 트랜잭션이 블록에 포함되었는지 확인할 때 거의 항상 이러한 중앙 집중식 공급자 중 하나를 통해 수행합니다.
기존 시스템의 문제점은 사용자가 공급자를 신뢰해야 하고 쿼리의 정확성을 확인할 방법이 없다는 것입니다.
엔터 버튼 Helios, 이더리움에 대한 완전 신뢰 없는 액세스를 제공하는 Rust 기반 이더리움 라이트 클라이언트입니다. Helios — 이더리움의 라이트 클라이언트 프로토콜을 사용하여 최근 스위치 에 스테이크의 증거 — 신뢰할 수 없는 중앙 집중식 RPC 공급자의 데이터를 검증 가능한 안전한 로컬 RPC로 변환합니다. Helios는 중앙 집중식 RPC와 함께 작동하여 전체 노드를 실행하지 않고도 진위를 확인할 수 있습니다.
이식성과 탈중앙화 사이의 절충점은 일반적인 문제이지만, 우리가 구축할 수 있도록 대중에게 제공한 우리의 클라이언트는 약 XNUMX초 만에 동기화하고 저장소가 필요하지 않으며 사용자가 다음에서 보안 체인 데이터에 액세스할 수 있도록 합니다. 모든 장치(휴대폰 및 브라우저 확장 프로그램 포함). 그러나 무엇 중앙 집중식 인프라에 의존할 때의 잠재적인 함정은 무엇입니까? 우리는 이 게시물에서 그것들이 어떻게 작용할 수 있는지 다루고, 우리의 디자인 결정을 살펴보고, 다른 사람들이 코드베이스.
중앙 집중식 인프라의 함정: 이더리움의 "어두운 숲"에 있는 이론적 생물
(이론적) 생물은 어두운 숲. 이것은 Ethereum mempool에서 먹이를 사냥하지 않고 대신 우리가 의존하게 된 중앙 집중식 인프라를 모방하여 함정을 설정합니다. 이 함정에 빠진 사용자는 실수를 하지 않습니다. 자신이 가장 좋아하는 탈중앙화 거래소를 방문하여 합리적인 슬리피지 허용 범위를 설정하고 평소와 같이 토큰을 사고 팔고 있습니다. 이더리움의 다크 포레스트: RPC 공급자의 입구에 세심하게 설정한 함정인 샌드위치 공격.
자세히 설명하기 전에 분산형 거래소에서 거래가 어떻게 작동하는지 살펴보겠습니다. 사용자가 스왑 트랜잭션을 보낼 때 스왑할 토큰, 스왑 금액, 가장 중요한 것은 트랜잭션이 진행되기 위해 사용자가 받아야 하는 최소 토큰 수와 같은 몇 가지 매개변수를 스마트 계약에 제공합니다. 이 마지막 매개변수는 스왑이 "최소 출력"을 충족하거나 되돌려야 함을 지정합니다. 이는 트랜잭션이 멤풀로 전송될 때와 블록에 포함될 때 사이에 발생할 수 있는 최대 가격 변동을 효과적으로 설정하기 때문에 종종 "슬리피지 허용 오차"로 알려져 있습니다. 이 매개변수가 너무 낮게 설정되면 사용자는 더 적은 수의 토큰을 받을 가능성을 받아들입니다. 이 상황은 공격자가 두 개의 악의적인 스왑 사이에 입찰가를 효과적으로 끼워 넣는 샌드위치 공격으로 이어질 수도 있습니다. 스왑은 현물 가격을 높이고 사용자의 거래가 덜 유리한 가격으로 실행되도록 합니다. 그런 다음 공격자는 즉시 판매하여 작은 이익을 얻습니다.
이 최소 출력 매개변수가 공정한 값에 가깝게 설정되는 한 샌드위치 공격으로부터 안전합니다. 그러나 RPC 공급자가 분산형 거래소 스마트 계약에서 정확한 가격 견적을 제공하지 않으면 어떻게 될까요? 그런 다음 사용자는 더 낮은 최소 출력 매개변수를 사용하여 스왑 트랜잭션에 서명하도록 속일 수 있으며 설상가상으로 트랜잭션을 악의적인 RPC 공급자에게 직접 보냅니다. 수십 개의 봇이 샌드위치 공격을 수행하기 위해 경쟁하는 공개 멤풀에 이 트랜잭션을 브로드캐스트하는 대신 공급자가 이를 보류하고 공격 트랜잭션 번들을 Flashbots에 직접 전송하여 자체 수익을 확보할 수 있습니다.
이 공격의 근본 원인은 블록체인의 상태를 가져오기 위해 다른 사람을 신뢰하는 것입니다. 숙련된 사용자는 전통적으로 자체 이더리움 노드를 실행하여 이 문제를 해결했습니다. 최소한 지속적으로 온라인 상태인 시스템, 수백 기가바이트의 스토리지, 처음부터 동기화하는 데 하루 정도가 필요한 시간과 리소스 집약적인 노력입니다. 이 과정은 확실히 예전보다 쉽습니다. 같은 그룹 ARM의 이더리움 저렴한 하드웨어(예: 외장 하드 드라이브가 연결된 Raspberry Pi)에서 노드를 실행할 수 있도록 끊임없이 노력했습니다. 그러나 이러한 상대적으로 최소한의 요구 사항에도 불구하고 대부분의 사용자, 특히 모바일 장치를 사용하는 사용자에게 노드를 실행하는 것은 여전히 어렵습니다.
중앙 집중식 RPC 공급자 공격은 완전히 그럴듯하지만 일반적으로 단순 피싱 공격 — 그리고 우리가 설명하는 것은 아직 일어나지 않았습니다. Alchemy와 같은 대규모 공급자의 실적을 보면 의심할 여지가 거의 없지만 익숙하지 않은 RPC 공급자를 지갑에 추가하기 전에 추가 조사를 할 가치가 있습니다.
Helios 소개: Ethereum에 대한 완전 무신뢰 액세스
이더리움은 라이트 클라이언트 프로토콜(최근 지분 증명으로 전환하여 가능)을 도입함으로써 블록체인과 빠르게 상호 작용하고 최소한의 하드웨어 요구 사항으로 RPC 종점을 확인할 수 있는 흥미롭고 새로운 가능성을 열었습니다. 이달부터 병합, 우리는 새로운 라이트 클라이언트가 서로 독립적으로 등장하는 것을 보았습니다(길잡이 별, 후광, 그리고 자바스크립트 기반 케블라) 전체 노드를 사용하지 않고 효율적이고 신뢰할 수 없는 액세스라는 동일한 목표를 위해 다른 접근 방식을 취했습니다.
우리의 솔루션인 Helios는 약 XNUMX초 만에 동기화되고 저장소가 필요하지 않으며 Ethereum에 대한 완전 신뢰 없는 액세스를 제공하는 Ethereum 라이트 클라이언트입니다. 모든 이더리움 클라이언트와 마찬가지로 Helios는 실행 계층과 합의 계층으로 구성됩니다. 대부분의 다른 클라이언트와 달리 Helios는 두 계층을 긴밀하게 연결하므로 사용자는 단일 소프트웨어만 설치하고 실행하면 됩니다. (에리 곤 아카이브 노드에 직접 구축된 컨센서스 레이어 라이트 클라이언트를 추가함으로써 이 방향으로도 움직이고 있습니다.
어떻게 작동합니까? Helios 합의 계층은 이전에 알려진 비콘 체인 블록해시와 신뢰할 수 없는 RPC에 대한 연결을 사용하여 현재 블록과 검증 가능하게 동기화합니다. Helios 실행 계층은 이러한 인증된 비콘 체인 블록을 신뢰할 수 없는 실행 계층 RPC와 함께 사용하여 계정 잔액, 계약 저장, 트랜잭션 영수증 및 스마트 계약 호출 결과와 같은 체인 상태에 대한 임의 정보를 증명합니다. 이러한 구성 요소는 함께 작동하여 전체 노드를 실행할 필요 없이 사용자에게 완전히 신뢰할 수 없는 RPC를 제공합니다.
… 합의 계층에서
컨센서스 레이어 라이트 클라이언트는 비콘 체인 라이트 클라이언트를 따릅니다. 명세서, 그리고 비콘 체인의 동기화 위원회(Altair 하드 포크의 병합 이전에 도입됨)를 사용합니다. 동기화 위원회는 ~512시간 동안 서비스를 제공하는 27명의 검증인 중 무작위로 선택된 하위 집합입니다.
검증인이 동기화 위원회에 있으면 보이는 모든 비콘 체인 블록 헤더에 서명합니다. 위원회의 XNUMX분의 XNUMX 이상이 주어진 블록 헤더에 서명하면 해당 블록이 표준 비콘 체인에 있을 가능성이 높습니다. Helios가 현재 동기화 위원회의 구성을 알고 있다면 가장 최근의 동기화 위원회 서명에 대해 신뢰할 수 없는 RPC를 요청하여 체인의 머리를 자신 있게 추적할 수 있습니다.
BLS 덕분에 서명 집계에서 새 헤더의 유효성을 검사하는 데 한 번만 확인하면 됩니다. 서명이 유효하고 위원회의 XNUMX/XNUMX 이상이 서명한 경우 블록이 체인에 포함되었다고 가정하는 것이 안전합니다(물론 체인에서 재구성할 수 있지만 블록 완결성을 추적하면 더 엄격한 보증).
하지만 이 전략에는 분명히 누락된 부분이 있습니다. 바로 현재 동기화 위원회를 찾는 방법입니다. 이것은 신뢰의 뿌리를 얻는 것으로 시작됩니다. 약한 주관성 체크포인트. 이름이 당신을 겁먹게 하지 마십시오. 그것은 단지 우리가 보장할 수 있는 오래된 블록해시가 과거 어느 시점에 체인에 포함되었음을 의미합니다. 체크포인트의 정확한 나이 뒤에는 몇 가지 흥미로운 수학이 있습니다. 최악의 경우 분석은 약 XNUMX주를 제안하는 반면 더 실용적인 추정은 몇 개월을 제안합니다.
체크포인트가 너무 오래된 경우 이론적 공격 이는 노드가 잘못된 체인을 따르도록 속일 수 있습니다. 약한 주관성 체크포인트를 획득하는 것은 프로토콜의 대역 외입니다. Helios에 대한 우리의 접근 방식은 코드베이스에 하드코딩된 초기 체크포인트를 제공합니다(쉽게 재정의할 수 있음). 그런 다음 노드가 동기화될 때마다 향후 체크포인트로 사용하기 위해 가장 최근에 완성된 블록해시를 로컬에 저장합니다.
편리하게 비콘 체인 블록을 해시하여 고유한 비콘 블록해시를 생성할 수 있습니다. 즉, 노드에 전체 비콘 블록을 요청한 다음 이를 해시하고 알려진 블록 해시와 비교하여 블록 내용이 유효한지 증명하는 것이 쉽습니다. Helios는 이 속성을 사용하여 현재 동기화 위원회와 다음 동기화 위원회라는 두 가지 매우 중요한 필드를 포함하여 약한 주관성 체크포인트 블록 내부의 특정 필드를 가져오고 증명합니다. 결정적으로, 이 메커니즘은 라이트 클라이언트가 블록체인의 히스토리를 빠르게 전달할 수 있도록 합니다.
약한 주관성 체크포인트가 있으므로 현재 및 다음 동기화 위원회를 가져와 확인할 수 있습니다. 현재 체인 헤드가 체크포인트와 동일한 동기화 위원회 기간 내에 있으면 서명된 동기화 위원회 헤더로 새 블록을 즉시 확인하기 시작합니다. 체크포인트가 여러 동기화 위원회 뒤에 있는 경우 다음을 수행할 수 있습니다.
- 체크포인트 이후에 다음 동기화 위원회를 사용하여 미래에 하나의 동기화 위원회를 생성하는 블록을 가져오고 확인합니다.
- 이 새로운 블록을 사용하여 새로운 다음 동기화 위원회를 가져옵니다.
- 여전히 뒤에 있으면 1단계로 돌아갑니다.
이 프로세스를 반복할 때마다 체인 기록의 27시간을 빨리 감기하고 과거의 블록 해시로 시작하여 현재 블록 해시와 동기화할 수 있습니다.
...실행 계층에서
실행 계층 라이트 클라이언트의 목표는 컨센서스 계층에서 검증된 비콘 블록 헤더를 가져오고 이를 신뢰할 수 없는 실행 계층 RPC와 함께 사용하여 검증된 실행 계층 데이터를 제공하는 것입니다. 이 데이터는 Helios에서 로컬로 호스팅하는 RPC 서버를 통해 액세스할 수 있습니다.
다음은 이더리움에 상태가 저장되는 방법에 대한 빠른 입문서로 시작하여 계정 잔액을 가져오는 간단한 예입니다. 각 계정에는 계약 코드 해시, nonce, 스토리지 해시 및 잔액과 같은 몇 가지 필드가 있습니다. 이 계정은 수정된 대규모 파일에 저장됩니다. 머클-패트리샤 나무 상태 트리라고 합니다. 상태 트리의 루트를 알면 다음을 확인할 수 있습니다. 머클 증명 트리 내 계정의 존재(또는 제외)를 증명합니다. 이러한 증거는 사실상 위조가 불가능합니다.
Helios는 합의 계층에서 인증된 상태 루트를 가지고 있습니다. 이 루트를 사용하여 와 신뢰할 수 없는 실행 계층 RPC에 대한 머클 증명 요청을 통해 Helios는 이더리움에 저장된 모든 데이터를 로컬로 확인할 수 있습니다.
실행 계층에서 사용하는 모든 종류의 데이터를 확인하기 위해 다양한 기술을 적용합니다. 함께 사용하면 신뢰할 수 없는 RPC에서 검색된 모든 데이터를 인증할 수 있습니다. 신뢰할 수 없는 RPC는 데이터 액세스를 거부할 수 있지만 더 이상 잘못된 결과를 제공할 수 없습니다.
야생에서 Helios 사용하기
이식성과 탈중앙화 사이의 절충점은 일반적인 골칫거리입니다. 그러나 Helios는 매우 가볍기 때문에 사용자는 모든 장치(휴대폰 및 브라우저 확장 포함)에서 보안 체인 데이터에 액세스할 수 있습니다. 어디에서나 Helios를 실행할 수 있는 기능을 통해 더 많은 사람들이 하드웨어에 관계없이 신뢰할 수 없는 Ethereum 데이터에 액세스할 수 있습니다. 즉, 사용자는 Helios를 MetaMask에서 RPC 공급자로 사용할 수 있으며 다른 변경 없이 dapp에 신뢰할 수 있게 액세스할 수 있습니다.
게다가, WebAssembly에 대한 Rust의 지원은 앱 개발자가 Javascript 애플리케이션(지갑 및 dapp과 같은) 내부에 Helios를 포함하는 것을 쉽게 가능하게 합니다. 이러한 통합은 이더리움을 더 안전하게 만들고 중앙 집중식 인프라를 신뢰해야 할 필요성을 줄여줍니다.
우리는 커뮤니티가 어떻게 나올지 기대하고 있습니다. 그러나 그동안 Helios에 기여할 수 있는 방법은 많이 있습니다. 코드베이스에 기여하는 데 관심이 없다면 Helios를 통합하여 이점을 활용하는 소프트웨어를 구축할 수도 있습니다. 다음은 우리가 기대하는 몇 가지 아이디어에 불과합니다.
- RPC를 통하지 않고 P2P 네트워크에서 직접 라이트 클라이언트 데이터 가져오기 지원
- 누락된 RPC 메서드 중 일부 구현
- WebAssembly로 컴파일되는 Helios 버전 빌드
- Helios를 지갑 소프트웨어에 직접 통합
- WebAssembly를 사용하여 웹사이트에 포함된 Helios에서 데이터를 가져오는 토큰 잔액을 볼 수 있는 웹 대시보드 구축
- Helios의 합의 레이어가 기존 실행 레이어 전체 노드에 연결될 수 있도록 엔진 API 구현
코드베이스를 확인하세요 시작하려면 버그 보고서, 기능 요청 및 코드를 환영합니다. 그리고 당신이 무언가를 더 만들면 우리와 공유하십시오. 트위터, 텔레그램, 또는 Farcaster @a16zcrypto.
***
여기에 표현된 견해는 인용된 개별 AH Capital Management, LLC("a16z") 직원의 견해이며 16z 또는 그 계열사의 견해가 아닙니다. 여기에 포함된 특정 정보는 16z가 관리하는 펀드의 포트폴리오 회사를 포함하여 제16자 출처에서 얻은 것입니다. 신뢰할 수 있는 출처에서 가져왔지만 16z는 이러한 정보를 독립적으로 확인하지 않았으며 정보의 현재 또는 지속적인 정확성 또는 주어진 상황에 대한 적절성에 대해 어떠한 진술도 하지 않습니다. 또한 이 콘텐츠에는 타사 광고가 포함될 수 있습니다. XNUMXz는 그러한 광고를 검토하지 않았으며 여기에 포함된 광고 콘텐츠를 보증하지 않습니다.
이 콘텐츠는 정보 제공의 목적으로만 제공되며 법률, 비즈니스, 투자 또는 세금 관련 조언에 의존해서는 안 됩니다. 그러한 문제에 관해서는 자신의 고문과 상의해야 합니다. 증권 또는 디지털 자산에 대한 언급은 설명을 위한 것일 뿐이며 투자 추천이나 투자 자문 서비스 제공을 의미하지 않습니다. 또한, 이 콘텐츠는 투자자 또는 예비 투자자를 대상으로 하거나 사용하도록 의도되지 않았으며, 어떤 상황에서도 a16z가 관리하는 펀드에 투자하기로 결정할 때 의존할 수 없습니다. (16z 펀드에 대한 투자 제안은 사모 투자 각서, 청약 계약서 및 해당 펀드의 기타 관련 문서에 의해서만 이루어지며 전체 내용을 읽어야 합니다.) 언급되거나 언급된 모든 투자 또는 포트폴리오 회사 설명된 내용은 16z가 관리하는 차량에 대한 모든 투자를 대표하는 것은 아니며 투자가 수익성이 있거나 미래에 수행되는 다른 투자가 유사한 특성 또는 결과를 가질 것이라는 보장이 없습니다. Andreessen Horowitz가 관리하는 펀드의 투자 목록(발행자가 16z가 공개적으로 공개하도록 허가하지 않은 투자 및 공개적으로 거래되는 디지털 자산에 대한 미고지 투자 제외)은 https://a16z.com/investments에서 볼 수 있습니다. /.
내부에 제공된 차트와 그래프는 정보 제공의 목적으로만 사용되며 투자 결정을 내릴 때 의존해서는 안 됩니다. 과거의 성과는 미래의 결과를 나타내지 않습니다. 내용은 표시된 날짜 현재만 말합니다. 이 자료에 표현된 모든 예측, 추정, 예측, 목표, 전망 및/또는 의견은 예고 없이 변경될 수 있으며 다른 사람이 표현한 의견과 다르거나 반대될 수 있습니다. 추가 중요 정보는 https://a16z.com/disclosures를 참조하십시오.
