Eth2.0의 중계자 네트워크 및 수수료 메커니즘
편집자 주: 이 기사의 출처는이더리움 애호가(ID: ethfans), 저자: John Adler, 번역가 및 교정자: IAN LIU & A Jian, 승인을 받아 Odaily에서 복제.
배경
배경
릴레이 네트워크에 뛰어들기 전에 이더리움의 주요 병목 현상(또는 병목 현상의 부족) 중 하나인 상태를 검토해 보겠습니다.
이더리움에서 상태는 계정 잔액, 계약 코드 및 계약 저장 내용의 모음을 의미합니다(비트코인에서 상태는 UTXO의 모음을 나타냄). 트랜잭션이 실행될 때마다 상태(~45GB의 비압축 데이터)를 읽고 씁니다. 이전에는 사람들이 이더리움 컴퓨팅 모델의 고유한 비확장성에 의문을 제기했지만, 오늘날 트랜잭션 실행에 대한 비용 병목 현상이 된 것은 상태의 읽기 및 쓰기이며 디스크의 I/O 성능은 실행에 대한 병목 현상이 되었습니다. 이더리움 전체 네트워크 노드 제약.
상태 저장 패러다임(상태 저장 패러다임)에 따라 트랜잭션을 실행할 수 있으려면 전체 노드가 모든 상태가 항상 액세스 가능한 위치(예: 메모리, 스왑 공간)에 배치되도록 해야 합니다. 단일 블록체인 시나리오에 적용한다면 이는 거의 받아들일 수 없는 수준일 수 있지만, 일단 파편화와 파편화 위원회의 재편에 직면했을 때, 이 요구 사항은 매우 불합리합니다. 검증자가 샤드 체인에 할당될 때마다 샤드의 모든 상태를 동기화해야 한다고 가정하면 이 시스템은 이때 블록 크기가 샤드 블록 크기와 같다는 점을 제외하면 단일 블록체인과 동일합니다. 샤드 수.
보조 제목
샤딩 및 상태 비저장 클라이언트
상태 비저장 클라이언트 패러다임(이전에는 "스토리지리스"라고 함)에서 유효성 검사기는 압축된 블록체인 상태 테이블(종종 누산기라고도 함)만 저장하면 되므로 트랜잭션 실행의 부담이 크게 줄어듭니다. 일반적으로 누산기의 크기는 일정하지만(예: 상태의 머클 트리 루트 값) 로그 크기일 수도 있습니다.
상태 비저장 클라이언트의 본질은 각 트랜잭션이 트랜잭션을 실행하는 데 필요한 모든 정보를 포함하는 현재 누산기의 증인 데이터(증인)를 수반한다는 것입니다. Ethereum에서는 Sparse Merkle Tree(SMT, Sparse Merkle Tree)를 누산기로 사용하여 트랜잭션에 관련된 모든 상태 요소를 Merkle 트리 분기에 포함할 수 있습니다.
다른 애플리케이션에서 상태 비저장 클라이언트는 Beam Sync의 원리인 Ethereum 노드의 초기 동기화 시간을 단축할 수 있습니다.
비고: Merkle 누산기보다 성능이 좋은 일부 암호화 누산기(예: RSA 누산기)가 있지만 이러한 누산기는 신뢰할 수 있는 초기화가 필요하거나 검증되지 않은 최첨단 암호화 기술을 사용하므로 프로덕션 시스템에 배포하는 것이 안전하지 않습니다. 시간이 좀 걸립니다.
그러나 상태 비저장 클라이언트에는 고유한 문제가 있습니다. 일단 Merkle 누산기가 사용되면 증인은 전체 실행이 끝날 때마다 만료됩니다. 모델에서 각 트랜잭션에 별도의 증인이 포함된 다음 이러한 트랜잭션을 순차적으로 실행해야 하는 경우 이후 트랜잭션의 증인 데이터는 최신이 아니므로 각 이전 트랜잭션이 완료되면 자체 증인을 업데이트할 수 있어야 합니다. 다행스럽게도 이러한 Merkle 누산기의 증인 업데이트에는 제로 해싱 오버헤드 접근 방식이 포함됩니다. 증인 데이터를 트랜잭션의 "빅 백"에 부속물로 추가할 수 있는 경우 각 트랜잭션에 속한 개별 증인을 업데이트할 필요가 없습니다. 또는 여러 증명에 통합할 수 있습니다(다중 증명).
모든 사용자가 풀 노드를 유지하고 실시간으로 증인 상태를 업데이트하면 상태 비저장 클라이언트 시스템을 즉시 채택할 수 있습니다. 불행하게도 샤드 환경에서 이것은 모든 사용자가 자신의 샤드에서 모든 상태를 유지해야 한다는 것을 의미하며, 이는 비실용적일 뿐만 아니라 위에서 언급한 것처럼 더 큰 크기의 블록을 생성하는 것과 같습니다. .
이 문제를 해결하기 위해 릴레이어(상태 제공자라고도 함) 개념이 여기에 도입되었습니다. 중계자는 사용자가 요구하는 증인을 제공할 책임이 있으며 사용자에게 서비스 비용을 청구합니다. 사용자와 달리 릴레이어는 단일 샤드에 서비스를 집중할 수 있습니다. 얻기 위해.
보조 제목
중계망 및 수수료 시장 제안
Ethereum 2.0 Phase 2의 설계 공간은 매우 넓고 실행 모드에 대한 많은 제안이 있었습니다. 각 제안은 릴레이 네트워크 메커니즘과 결합된 지불을 통해 사용자와 블록 제안자 간의 거래를 더 잘 전달하는 방법을 표현합니다. 이 장에서는 다양한 프로토콜을 가능한 한 간결하고 포괄적으로 요약하고 릴레이 네트워크 및 수수료 메커니즘의 유사점과 차이점을 분석하는 데 중점을 둡니다.
Collator 제안(더 이상 사용되지 않음)
이것은 샤드 체인의 빌딩 블록을 제안자, 조합자 및 집행자의 세 부분으로 나누는 2단계의 초기 제안입니다. 일부 제안자는 트랜잭션을 수집하고 블록으로 패키징(데이터 정렬이라고도 함)하고, 일부 제안자는 데이터 정렬을 체인에 제출(블록으로 전환)하며, 마지막으로 실행자는 제안된 데이터 정렬을 기반으로 새로운 상태 루트를 제공합니다. .
이 제안은 완전히 연구되지 않았으므로 수수료 지불 메커니즘에 대한 연구도 없었습니다. 다른 요인과는 별개로, 이 제안은 인센티브 메커니즘이 사용자가 동시에 제안자, 보증인 및 집행자가 되어 혜택을 극대화하도록 장려하기 때문에 포기되었습니다.
Phase 1 and Done
Casey Detrio는 자신의 선구적인 블로그 게시물 "1단계 및 완료: 데이터 가용성 엔진-Ethereum 2.0"에서 다음과 같이 강조했습니다. 이 체계에서 샤드는 1) 데이터 인증(즉, Merkle 트리와 같은 인식된 데이터 구조에 일련의 트랜잭션 삽입), 2) 승인된 데이터에 대한 영지식 증명 유효성 검사와 같은 간단한 상태 비저장 작업을 수행합니다.
데이터 블록 핸들러는 컨트랙트를 비콘 체인에 업로드하여 정의할 수 있습니다(컨트랙트는 향후 "프리컴파일"로 변환된 후 "실행 환경"이 됩니다). 클라이언트에 의해 구문 분석되는 것은 전체 프로토콜의 내용에 따라 다릅니다.
"1단계 및 완료"는 수수료 지불 메커니즘에 대한 대부분의 질문을 회피합니다. 지불 메커니즘 문제는 이전 제안에 존재했고 계속 존재할 것이기 때문에 제안은 대신 이를 Eth2의 장기 사용으로 정의하려고 시도합니다. .0. 최소한의 변경 사항이 있으며 곧 알 수 있기를 바랍니다. 또 다른 제안은 Ethereum 1.x에서 계약을 통해 수수료를 지불하는 것입니다(블록 제안자는 Ethereum 2.0에서 처리되고 사용 가능한 데이터 블록을 제공한 다음 제안자에게 지불합니다). 이더리움 1.x에서.
Phase 2 Proposal 1
Detrio의 연구에 이어 Vitalik Buterin은 2단계에 대한 구체적이고 새로운 제안인 2단계 제안 1을 제시했습니다. 이 제안에서 실행 스크립트(원래 "비콘 체인 계약"이라고 함)는 비콘 체인에 저장되고 ETH는 실행 스크립트에 입금될 수 있으며(수수료를 지불하기 위해) 절대 비콘 체인을 떠나지 않습니다. 각 샤드의 상태와 실행은 완전히 독립적입니다.
그들의 이름은 오해의 소지가 있을 수 있습니다. 실행 스크립트는 오늘날 이더리움에서 볼 수 있는 스마트 계약이 아니라 트랜잭션을 실행하는 가상 머신을 정의하는 규칙입니다. 실행 스크립트는 클라이언트가 구문 분석, 측정 및 인코딩(예: ewasm 코드)할 수 있는 방식으로 데이터 모델 및 opcode를 정의해야 합니다.
수수료를 지불하기 위해 각 실행 스크립트는 기본적으로 레이어 2 시스템이며 검증자는 내부 지불 메커니즘을 "알" 수 없습니다. 이는 설계 결함이 아니라 의도적입니다. 샤드 검증자가 다른 수수료 메커니즘(다른 통화와 관련될 수 있음)을 구문 분석하고 계산해야 하는 경우 의심할 여지 없이 구현의 어려움과 경제 메커니즘의 복잡성이 크게 증가할 것입니다. , 악용될 수 있거나 심지어 완전히 사용할 수 없게 되는 더 많은 약점을 소개합니다. 대체로 "경제적 추상화"에 반대하는 주장은 대본에 따라 수수료 유형을 정의하는 이러한 유형의 실행 모델에 대해서도 사용될 수 있습니다(번역자 주: "경제적 추상화"는 "수수료 일반화"라고도 합니다. 프로토콜 계층은 사용자와 검증자가 처리 수수료를 지불하는 데 사용되는 토큰을 사용자 정의하도록 지원합니다.일부 사람들은 이로 인해 기본 토큰이 가치를 잃을 것이라고 생각합니다.)
유효성 검사기는 스크립트 실행에서 직접 수수료를 받을 수 없기 때문에 다른 방법을 통해 서비스 수수료를 받아야 합니다. 이것은 특별한(즉, enshrined type) 실행 스크립트로 이루어지며, 누구나 다음과 같은 논리를 포함하는 트랜잭션을 보낼 수 있습니다. 이 데이터 블록을 기록한 사람에게 수수료"; 여기서 작업은 모두 중계자(운영자라고도 함)가 수행합니다. 중계자는 비보장 공통 실행 스크립트에 따라 지정된 사용자 트랜잭션을 수집할 책임이 있습니다. 수수료는 다음에 따라 부과됩니다. 규칙, 그리고 샤드의 블록 제안자(빌더)는 암호화된 실행 스크립트에 따라 패키지된 트랜잭션에 대해 지불됩니다.
William Villanueva의 블로그 A Journey Through Phase 2 of Ethereum 2.0은 지금까지의 Phase 2 제안에 대한 완벽한 요약을 제공합니다.
Phase 2 Proposal 2
Detrio의 이전 작업에서 영감을 받아 V God은 제안 1을 단순화하고, 샤드 체인에서 상태를 제거하고, 비컨 체인을 사용하여 다양한 샤드 및 실행 환경을 추적하는 것을 목표로 2단계 제안 2를 다시 한 번 제안했습니다. 실행 스크립트) 다른 상태 루트.
이 설계의 장점은 서로 다른 실행 환경이 고유한 누산기(예: 스파스 머클 트리, 레드-블랙 트리, 암호화 누산기 등)를 선택할 수 있다는 것입니다. .
이제 일반적인 트랜잭션 흐름은 다음과 같습니다. 사용자가 트랜잭션을 생성하고 중계자에게 전송하면 중계자는 사용자가 사용자로부터 지불을 받아야 하므로 증인(Merkle 누산기를 사용하는 경우 Merkle 분기 형식)을 추가합니다. 그런 다음 릴레이어는 여러 트랜잭션을 패키지화하여 블록 제안자에게 함께 보내고 프로토콜의 내장 메커니즘을 통해 지불하므로 제안자는 트랜잭션 배치를 다음(샤드) 블록으로 패키지화할 수 있습니다. 제안 1과 마찬가지로 여기서 "프로토콜에 내장된 메커니즘"은 모든 검증자가 인식할 수 있는 상위 EE(인슈린드 EE)를 나타냅니다.
검증자의 경우 이 방식은 부담을 어느 정도 줄여주지만 위의 작업에는 여전히 일부 샤딩 상태가 필요하고 제안은 사용자와 릴레이어 간의 프로토콜 내 수수료 지불 메커니즘을 설계하지 않기 때문에 아직 해결되지 않았습니다. 릴레이 네트워크 문제. 첫째, 지불을 위해 프로토콜 외부의 수단을 사용하면 사용자 개인 정보가 약화되고 둘째, 사용자와 중계자가 손을 잡을 수 있도록 완전히 오프체인 시스템(다른 외부 블록체인에 의존하지 않음)을 만드는 방법이 명확하지 않습니다. -hand 돈은 한 손으로 전달됩니다(즉, 트랜잭션의 원자성), 셋째, 결제에 합의되지 않은 수단을 사용할 가능성이 높고 중계자가 되기 위해 필요한 높은 컴퓨팅 성능(만일 중계자가 EE 또는 샤드를 서비스하기를 원하고 증인을 생성할 수 있으려면 모든 상태가 저장되어야 함) 중앙 집중화 문제가 발생할 수 있습니다. 최악의 경우 사이에 몇 개의 "게이트키퍼" 중계만 남을 수 있습니다. 사용자와 이더리움 2.0 네트워크 By.
트랜잭션 버퍼 풀 모드로 돌아가기
새로운 제안에서 Vitalik은 릴레이어가 블록 제안자에게 조건부로 지불할 수 있도록 허용하려면 지불의 원자성을 보장하기 위해 무거운 이중 약정 방법이 필요하므로 모든 문제를 해결하기 위해 수수료 시장 EE를 사용하는 것이 좋습니다. 이 제안에서 EE는 자체 균형을 갖습니다. EE는 일련의 트랜잭션을 실행한 후 영수증을 출력하고 수수료 지불을 담당하는 상위 EE(enshrined EE)는 이 데이터를 기반으로 EE 계정에서 블록 제안자에게 이더리움을 전송합니다. 따라서 수수료를 지불하는 상위 EE는 이전 영수증을 "뒤돌아보고" 송금을 처리할 수 있습니다. EE 계정 재충전은 중계자(또는 다른 이해 관계자)의 책임일 수 있습니다.
이 제안의 장점은 중계자와 블록 제안자 간의 결제를 조율하기 위해 복잡한 방법을 사용할 필요가 없지만 사용자가 중계자와 상호 작용하는 방법을 지정하지 않고 결제 채널 사용을 권장한다는 것입니다. .
원래 제안을 기반으로 Villanueva는 트랜잭션 버퍼 풀 모델로 돌아갈 것을 제안했습니다. 이 경우 릴레이어는 트랜잭션을 패키징하지 않고 증인만 제공하는 상태 제공자 역할만 하면 됩니다. 각 EE는 서로 다른 누산기를 선택할 수 있으므로 블록 제안자가 여러 Merkle 분기를 하나의 Merkle 다중 증명으로 통합하는 것과 같이 두 개 이상의 증인을 통합할 수 있도록 EE는 증인을 병합하는 고정된 방법을 미리 선언해야 합니다.
상태 공급자는 증인(보통 Merkle 분기 형식)만 제공하면 되므로 이 작업에 이미 많은 역할(예: 라이트 클라이언트 서버)을 사용할 수 있습니다. 더 많은 라이트 클라이언트 서버는 증인에게 더 편리한 도구와 더 낮은 비용을 제공하도록 장려할 수 있으며, 이는 높은 안정성을 향한 먼 길을 갈 수 있습니다. 그럼에도 불구하고 마찰이 심한 지불 채널을 사용하여 국가 공급자에게 지불해야 하는 것은 사용자에게 골칫거리입니다.
2단계 대안 아키텍처
얼마 전 Vitalik은 샤딩 상태를 완전히 제거하려는 2단계 대안 아키텍처를 제안했습니다. 요점은 비콘 체인에 EVM과 같은 완전하고 상태가 풍부하며 표현적인 상태 전환 엔진이 추가된다는 것입니다. 이 엔진은 EE의 상태 루트를 추적하는 "스케줄러" 역할을 합니다. 스케줄러 설계는 또한 다중 샤드 트랜잭션 실행을 가능하게 합니다. 미리 결정된 순서로 샤드와 시간 슬롯을 확인하여 동일한 EE에 대한 샤드 전체의 여러 트랜잭션이 올바르게 실행되도록 합니다(실행 전 상태와 실행 후 상태 상태 루트를 확인하여). , 유효하지 않거나 순서가 잘못된 샤드 블록은 무시).
이 제안의 수수료 지불 메커니즘은 이전 제안과 변경되지 않았지만 발송자는 EE 잔액 관리 및 영수증 소비를 처리할 수 있는 충분한 용량을 가지고 있으므로 더 이상 특정 지불 수수료 EE가 존재할 필요가 없습니다.
샤드체인 단순화 제안
DevCon 5 컨퍼런스에서 Vitalik은 Near 프로토콜의 샤딩 블록인 Nightshade의 설계에서 영감을 받은 Ethereum 2.0 아키텍처의 주요 구조 조정을 발표했습니다. 새로운 제안에서는 각 샤드 체인이 독립적인 포크 선택 규칙을 실행하도록 요구하는 대신 블록과 교차 링크가 인터리브되어 더 빠른 속도로 블록 및 교차 링크를 생성하고 샤드의 블록이 비컨 체인 블록을 함께 생성하고 모든 샤드가 상호 연결됩니다. 모든 비콘 체인 블록과 연결됩니다(정상적인 상황에서). 아키텍처는 샤드 교차 링크 수를 늘립니다. 교차 링크 수의 증가에 따라 샤드 수가 1024개에서 64개로 감소하는 동시에 각 샤드의 처리량도 증가하여 전체 시스템 볼륨의 처리량은 원래 수준으로 유지됩니다.
위에서 언급한 사고 방식의 근본적인 변화는 수수료 시장을 더 간단하게 만듭니다. 샤드 수가 크게 줄어들기 때문에 교차 샤드 통신이 단순화되고 사용자는 각 샤드에 Ether를 직접 저장하고 수신자에게 블록 지불을 직접 제안할 수 있습니다. EE를 통한 영수증 출력에 대한 앞서 언급한 제안을 통해 다시).
보조 제목
상기시키다
Ethereum 2.0의 릴레이 네트워크/수수료 시장에 대한 위의 논의는 완전하지 않습니다.
사용자, 릴레이어, 블록 제안자 모두에게 적절한 지불 인센티브와 서비스가 필요합니다. 사용자는 지불을 통해 필요한 증인을 얻을 수 있고, 중개자는 증인을 제공하기 위해 수수료를 청구하고, 블록 제안자는 패키지 트랜잭션에 청구합니다. 중계자가 블록 제안자에게 지불하는 방식(또는 EE를 통해 간접적으로)은 계약에서 선언할 수 있지만 사용자는 트랜잭션이 패키지화되어 있음을 확인하면서 증인 데이터를 얻고 싶어하며 지불 방법은 그렇게 간단하지 않습니다.
사용자에게 좋은 결제 수단은 마찰이 적어 서로 다른 중계자 간에 쉽게 전환할 수 있어야 합니다. 그러나 외부 블록체인의 지불 채널에 따라 선불 보증금과 외부 체인의 활성에 대한 요구 사항이 있으며 이상적으로는 사용자 지불 문제가 계약 내에서 해결될 수 있습니다.
이전 요점에 이어 중계자가 사용자를 검열하기 어렵게 해야 합니다. 불행하게도 증인은 포함된 액세스 목록에서 가져오므로 중계자가 블랙리스트에 오르는 것을 막을 방법이 없습니다.
유효성 검사기는 각 EE 내부의 지불 방법을 "이해"할 필요가 없습니다. 이는 매우 복잡하고 배포 및 효율적인 시장 구축에 큰 장벽이 되기 때문입니다.
사용자는 전체 노드를 유지할 의무가 없습니다(예: 필요한 증인을 유지할 필요가 없음). 우리는 이 제안이 라이트 클라이언트에게 매우 우호적이기를 바랍니다.
요약하다
요약하다
지난 1년을 돌이켜보면 릴레이 네트워크와 수수료 시장에 대한 연구를 중심으로 여러 번의 반복이 수행되었습니다.우리는 검증자의 부담을 줄이고 액세스 프리를 보장하면서 사용자와 라이트 노드에게 좋은 사용자 경험을 제공하기 위해 최선을 다하고 있습니다. 가능한 한 많은 섹스에 접근하십시오. 앞으로 우리는 이더리움 2.0의 모든 측면을 더욱 개선하고 완성하는 2단계에 대한 더 많은 제안을 보기를 희망합니다!
참고: 원문 링크:https://medium.com/
