연구: 이더리움 2.0의 상태 제공자 모델

以太坊爱好者

特邀专栏作者

2020-03-27 07:00 (UTC+8)

이 기사는 약 5623자로, 전체를 읽는 데 약 9분이 소요됩니다

여러 상태 옵션을 사용할 수 있습니다.

AI 요약

여러 상태 옵션을 사용할 수 있습니다.

편집자 주: 이 기사의 출처는이더리움 애호가(ID: ethfans)편집자 주: 이 기사의 출처는

이더리움 애호가(ID: ethfans)

소개

, 저자: adietrichs, 번역 및 교정: Pei Qi & A Jian, 승인을 받아 Odaily에서 재인쇄함.

이 기사는 samwilsn 및 adietrichs와 공동 작성되었으며 villanuevawill 및 Quilt 팀의 큰 도움을 받았습니다.

소개

이더리움 2.0의 상태 비저장은 트랜잭션이 액세스하려는 상태를 전달해야 함을 의미합니다. 보다 정확하게는 블록 제안자(BP)의 경우 트랜잭션을 포함하는 것 외에도 블록은 모든 트랜잭션에서 액세스하는 모든 상태 및 해당 증인 정보를 포함해야 합니다. 트랜잭션을 생성하는 사용자나 BP가 상태 데이터를 저장하지 않는다고 가정하면 네트워크는 이러한 상태를 저장하고 제공하기 위해 다른 그룹이 필요합니다. 이 역할을 종종 상태 제공자(SP)라고 합니다.

블록 제안자와 상태 제공자가 상태를 교환하는 방법에 관계없이 사용자는 트랜잭션을 생성하기 전에 상태를 가져와야 할 수 있습니다. 예를 들어 계약의 바이트 코드를 얻거나 가스 비용을 추정하거나 계정 잔액을 확인합니다. 이는 상태 제공자가 사용자를 위해 풀과 유사한 인터페이스를 노출해야 함을 의미합니다. 인센티브 계층은 없지만 이타적인 상태 제공자에 의존하는 것만으로도 사용자에게 상태를 제공할 수 있으며(Ethereum 1.0이 이를 수행함) 상태 제공자에게 인센티브 계층을 추가하여 상태 채널을 통해 결제도 구현할 수 있습니다.

비교 기준

상태 액세스 제한

트랜잭션의 실행은 실행 당시의 상태를 기반으로 하기 때문에 기본 상태가 변경되면 트랜잭션의 실행도 변경됩니다. 특히 일부 트랜잭션의 경우 상태 액세스 위치가 변경될 수 있습니다. 이는 간단한 점프 문(예: if) 때문이거나 방문한 위치가 런타임에 계산되기 때문일 수 있습니다. 두 경우 모두 DSA(Dynamic State Access)라고 합니다. 상태 비저장 모드에서는 트랜잭션 생성 프로세스가 복잡해집니다. 문제는 이러한 트랜잭션에 미리 상태를 제공하는 것이 불가능할 수 있다는 것입니다(이 트랜잭션이 액세스할 전역 상태를 미리 알 수 없기 때문에). 서로 다른 상태 제공자 패턴은 이러한 트랜잭션을 지원하는 범위에서 다르게 작동합니다.

모드가 동적 상태 액세스를 제한하는 경우 Eth1은 Eth2 실행 환경(EE)이 되지 못할 가능성이 높으며 종종 특별한 처리가 필요합니다.

보조 제목
주 제공자에 대한 보수는 다음 두 가지 측면에서 비교됩니다.

누가 지불하고 보상은 어떻게 계산됩니까?

초기에 이타적 국가 제공자가 지원되고 있다면 나중에 인센티브를 추가할 수 있습니까?

보조 제목
중앙 집중화 위험
중앙 집중화 위험은 모델마다 다릅니다.

누가 거래를 검토할 수 있으며 어느 정도까지 가능합니까?

블록 제안자와 주 생산자 사이에 어느 정도의 상호 신뢰가 달성되어야 합니까?

시간 제약

블록 생산자가 블록을 브로드캐스팅하는 고정된 시간이 있습니다. 따라서 우리는 특정 시간 제한 내에서 다양한 모드가 어떻게 수행되는지 구체적으로 고려합니다.

보조 제목

Eth1에서 특정 트랜잭션에 대한 서명 확인과 잔액 및 논스 확인이 완료되면 채굴자는 트랜잭션을 포함하여 지불될 것이라고 확신할 수 있습니다. Eth2에서 블록 제안자가 보상을 받을 수 있는지 여부는 손실된 상태가 귀속 오류인지 여부에 따라 다릅니다. 그렇다면 상태 손실로 인해 트랜잭션이 실패하더라도 블록 제안자는 여전히 지불을 받을 수 있습니다. 그렇지 않으면 손실 상태 트랜잭션 자체는 압축 해제할 수 없지만 블록 제안자는 모든(일반적으로 긴) 트랜잭션이 실행될 때까지 이를 발견하지 못할 수 있습니다. (번역자 주: 여기서 결제는 블록 제안자가 패키지 트랜잭션에서 트랜잭션 수수료를 부과해야 함을 의미합니다. 귀책사유가 없는 오류인 경우 블록 제안자는 트랜잭션을 패키지하기 위해 비용을 지출하지만 블록 제안자는 트랜잭션을 가져오지 않습니다. 거래 수수료.)

블록 제안자가 오류를 찾기 위해 트랜잭션을 실행해야 하지만 이러한 트랜잭션이 패키징되지 않은 경우(즉, 트랜잭션 수수료를 지불할 수 없는 경우) 블록 제안자는 거의 비용이 들지 않는 서비스 거부 공격에 취약합니다.

모델

보조 제목

직접 푸시 모델

상태 액세스 제한

자극

트랜잭션을 생성하는 사용자는 기본적으로 트랜잭션에 대한 유일한 상태 제공자가 됩니다. 일반적으로 말해서, 미래에 트랜잭션이 온체인될 때 사용자가 제공한 상태가 모든 액세스 요구를 충족할 수 있는지 확인할 방법이 없습니다. 따라서 Direct Push 모드에서는 예측 가능한 상태 액세스가 있는 트랜잭션만 실행할 수 있습니다. 트랜잭션은 정적 상태를 통해서만 액세스할 수 있기 때문에 계약 작성자는 예측 가능한 상태 액세스를 갖도록 계약을 설계해야 합니다. 액세스 목록과 같은 주석을 사용하여 런타임 중에 계약이 액세스할 수 있는 위치를 자세히 설명할 수 있습니다. 동적 상태 액세스를 피하는 패턴과 결합된 이 접근 방식(Eth1.x에 대한 Vitalik의 관련 블로그 게시물 참조)은 여전히 충분한 기능을 제공해야 하는 새로운 패턴을 생성해야 합니다.

그러나 이것은 현재 Eth1 시스템에서 크게 벗어나는 것입니다. Eth1을 Eth2로 전환하려는 계획을 망칠 수 있습니다.

자극

이 패턴은 일반 상태 공급자 네트워크에만 의존합니다. 위에서 언급했듯이 인센티브 시스템 없이도 가능할 것 같습니다.

지불 채널을 통해 인센티브 시스템을 추가할 수도 있습니다. 각 사용자가 하나 이상의 상태 제공자와 결제 채널을 설정해야 한다는 점을 감안할 때 이 접근 방식은 특히 복잡해야 합니다.

중앙 집중화 위험

사용자가 여러 상태 공급자에게 여러 쿼리를 보낼 수 있으므로 단일 상태 공급자는 트랜잭션을 검열할 수 없습니다.

상태 공급자는 상태의 일부만 유지할 수 있으므로 필요에 따라 하드웨어 요구 사항을 줄일 수 있습니다.

금전적 인센티브는 일부 국가 제공자가 중앙 집중화하도록 장려할 수 있으므로 사용자가 지불 채널을 통해 국가를 구매할 때 상대를 신뢰해야 합니다.

시간 제약

시간 제약이 없습니다.

잃어버린 상태의 속성
핵심

주요 이점: 단순성. 전문 상태 제공자 또는 인센티브 시스템이 필요하지 않습니다. 특별한 시간 제약은 없습니다.

주요 단점: 모든 상태 액세스 요구 사항이 미리 알려진 트랜잭션에만 적합합니다. 이는 전체 시스템의 기능을 제한합니다. 일부 완화 방법을 사용할 수 있지만 호환성 문제를 해결할 수 없습니다. 특히 이 모델에서는 Eth1이 Eth2의 운영 환경이 될 수 없습니다.

보조 제목

릴레이 푸시 모델

이에 따라 트랜잭션 패키지 풀의 트랜잭션 패키지가 사용할 수 없는 것으로 확인된 경우에도 시스템을 계속 실행할 수 있습니다. 릴레이어는 트랜잭션 패킷의 존재만 알립니다. 블록 제안자는 릴레이어에게 직접 연락하여 거래 패키지를 받아 새 블록에 포함시킵니다.

자극

상태 액세스 제한

제한 없음. 릴레이어가 상태 액세스 요구를 충족할 수 있도록 각 슬롯(슬롯)마다 트랜잭션 패키지에 상태를 푸시할 수 있는 한 괜찮습니다. 또한 각 새 블록에는 하나의 데이터 패킷만 포함되어 트랜잭션 패킷 간의 간섭을 방지합니다.

자극
중계자에 대한 인센티브 메커니즘을 설계하는 것은 실제로 매우 복잡합니다. 상태 및 증인 정보가 공개되면 사용자 및/또는 BP는 증인을 우회하고 트랜잭션 패키지를 다시 만들 수 있기 때문입니다.

두 가지 가능한 솔루션:

트랜잭션 풀이 없으면 트랜잭션 패키지가 공개되지 않습니다. 중계자는 국가가 부여한 거래 패키지를 블록 제안자에게 판매(수수료는 거래 수수료보다 약간 낮음)하여 거래 패키지 시장을 형성합니다. 블록 제안자에게는 몇 가지 위험이 있습니다: 거래가 다른 블록에 포함되어 유효하지 않은 거래가 될 수 있거나, 받은 거래 수수료가 판매 시 중계자가 발표한 것보다 적습니다.

또는 트랜잭션 풀이 있거나 없는 특정 릴레이어에 대한 지불이 트랜잭션에 포함될 수 있습니다. 사용자는 사용자가 다른 트랜잭션을 생성하지 않는 독점 기간(즉, 몇 개의 시간 슬롯)을 커밋합니다. 사용자가 독점 기간 동안 동시에 2개 이상의 거래에 서명할 경우 불이익을 받게 됩니다. 이를 위해 EE는 사용자를 "슬래시"하는 방법을 제공해야 합니다. 그러나 사용자가 예치금을 잠그지 않기 때문에 계정 잔액이 충분하지 않은 사용자에게 벌금을 부과하는 방법이 명확하지 않습니다.
중앙 집중화 위험

중앙 집중화 위험은 사용되는 중계자 인센티브에 따라 다릅니다.

트랜잭션 번들 병합이 복잡하다는 점을 감안할 때(동적 상태 액세스로 인해) 트랜잭션 번들 마켓플레이스는 높은 중앙 집중화로 이어지고 개별 중계자가 트랜잭션을 검토할 수 있도록 합니다. 위 목록에서 BP가 겪을 수 있는 위험 때문에 BP는 잘 알려져 있고 신뢰할 수 있는 중계자와 협력하는 것을 선호합니다. 이러한 잘 알려진 중계자와 비교할 때 개인 사용자는 거래 수수료가 충분히 높은 거래 패키지를 제공할 수 없습니다.

독점 기간과 거래 풀을 사용하면 높은 수준의 탈중앙화가 가능하지만 사용자 편의성과 거래 풀 구현이 더 복잡해집니다. 이론적으로 모든 사용자는 트랜잭션 풀에서 트랜잭션 패키지를 검색하고 자신의 트랜잭션을 추가하여 트랜잭션 패키지를 확장한 다음 더 높은 트랜잭션 수수료로 트랜잭션 패키지를 릴레이할 수 있습니다.

시간 제약

모든 유형의 트랜잭션을 지원하려면 블록에 포함된 모든 트랜잭션 패키지가 최신 상태를 포함해야 합니다. 중계자는 이전 블록을 다운로드하고 트랜잭션 패키지에 해당하는 업데이트를 생성하여 블록 제안자에게 보내야 하며 블록 제안자는 업데이트된 트랜잭션 패키지를 새 블록에 포함합니다. 이러한 모든 작업은 슬롯 시간 내에 완료되어야 합니다. .

잃어버린 상태의 속성
상태 손실은 중계자에 기인할 수 있습니다. 블록 제안자는 릴레이어(또는 릴레이어가 자발적으로 선택)에게 상태 손실로 인해 트랜잭션이 실패할 때 블록 제안자에게 환불하는 데 사용되는 "환불 트랜잭션"을 트랜잭션에 첨부하도록 요청할 수 있습니다.

핵심
주요 이점: 상태 액세스 제한이 없습니다.
결점:
트랜잭션 풀이 없으면 트랜잭션 패키지를 결합할 수 없으므로 블록은 단일 릴레이어가 제안한 트랜잭션 패키지만 포함할 수 있습니다. 릴레이어는 검열을 중앙 집중화하고 도입할 수 있습니다.

트랜잭션 풀이 있더라도 트랜잭션 번들의 조합이 검열 문제를 완전히 완화하기에 충분한지 여부는 불확실합니다.

인센티브 시스템은 복잡합니다.

보조 제목

풀 모델(풀 모델)

사용자는 트랜잭션을 네트워크로 보내고 노드는 보류 중인 트랜잭션 풀을 유지합니다. 블록을 생성하기 전에 블록 제안자는 트랜잭션 풀에서 보류 중인 일부 트랜잭션을 선택하고 트랜잭션 패키지를 구성한 다음 트랜잭션 패키지의 상태를 요청하기 위해 상태 제공자에게 보냅니다. 상태를 수신한 후 블록 공급자는 트랜잭션 패키지를 새 블록으로 압축합니다.

상태 제공자가 모든 상태를 제공하기 전에 중간 노드와 블록 제안자가 트랜잭션의 유효성을 확인하기 위해 사용자는 서명 및 수수료 지불 능력을 확인하는 데 필요한 증인 메시지를 트랜잭션에 첨부해야 합니다. 따라서 이 부분은 서로 다른 실행 환경(EE)에 걸쳐 표준화되어야 하며 모든 EE는 가장 간단한 검증 기능을 위한 옵션을 제공해야 합니다.

또는 가치 보유 EE(VHEE)를 사용할 수 있습니다. 모든 거래는 이 VHEE를 사용하여 수수료를 지불합니다. 네트워크의 노드는 트랜잭션 유효성을 확인할 수 있도록 VHEE를 이해합니다.

두 경우 모두 네트워크의 노드는 새 블록이 도착하면 연결된 상태의 증인 정보를 업데이트해야 합니다.

상태 액세스 제한

자극

기본 트랜잭션에는 제한이 없습니다. 블록 제안자는 반환된 상태가 최신 상태인지 확인하기 위해 블록을 생성할 때 상태 공급자에게만 연락합니다. 더 중요한 것은 트랜잭션을 번들로 묶고 트랜잭션 번들 단위로 상태를 요청함으로써 상태가 정확한 컨텍스트에 연결된다는 것입니다. 이 접근 방식은 제공된 상태가 항상 충분함을 보장합니다. 여기에는 Direct Push 모드와의 주요 차이점이 포함됩니다 Direct Push 모드에서는 트랜잭션이 묶이기 전에 상태가 추가되므로 상태 액세스가 제한됩니다.

사용자가 서명을 검증한 상태와 수수료를 지불할 수 있는 능력을 포함해야 하므로 거래 부분에 대한 제한은 기술적으로 Direct Push 모델에 나열된 것과 동일합니다. 그러나 이러한 제한은 실제로 중요하지 않습니다. Eth1에서는 서명 확인 및 수수료 지불이 예측 가능한 상태 액세스이므로 Eth1과 Eth2 간의 호환성이 깨지지 않습니다. 또한 VHEE의 경우 설계가 예측 가능한 상태 액세스를 보장하므로 추가 제한이 필요하지 않습니다.

자극

블록 제안자는 지불 채널 또는 기타 수단을 통해 상태 공급자가 제공하는 상태에 대해 지불할 수 있습니다. BP와 거래상대방 SP의 신뢰 정도에 따라 거래 건수에 따라 수수료를 지불하거나(이것이 신뢰 최소화), 거래 패키지에 따라 지불할 수 있습니다(이것이 더 효율적입니다)

중앙 집중화 위험

상태 제공자는 모든 상태를 저장해야 하며 스토리지 요구 사항이 매우 큽니다. 상태 공급자는 또한 트랜잭션 패키지를 신속하게 실행할 것으로 예상되므로 계산 능력이 필요합니다.

블록 제안자는 신뢰할 수 있는 상태 제공자 그룹에서 상태를 얻는 경향이 있어 악의적 손상의 위험을 줄이고 중앙 집중화 정도를 높일 수 있습니다.

그러나 단일 상태 제공자는 트랜잭션 패키지 생성 및 주문을 담당하는 블록 제안자이기 때문에 트랜잭션을 검열할 수 없습니다. 상태 공급자가 특정 트랜잭션 패키지에 필요한 상태를 숨길 수 있지만 그렇게 하면 평판이 손상될 수 있으며 블록 제안자는 다른 상태 공급자와 쉽게 재시도할 수 있습니다.

시간 제약

블록 제안자는 시간 슬롯 내에 업로드할 트랜잭션 패키지에 필요한 상태를 TA에 제공할 수 있는 상태 제공자에게 연락해야 합니다.