블록체인의 상태 폭발 딜레마

보조 제목

레이어 1은 상태에 집중해야 합니다.

블록체인 레이어링이 미래의 개발 방향이라고 믿는다면 처음부터 상위 레이어 프로토콜과 레이어드 네트워크의 요구 사항을 고려하고 레이어드 프레임워크에서 블록체인 프로토콜을 설계해야 합니다.

즉, 계층적 관점에서 볼 때 기존 블록체인 디자인은 시대에 뒤떨어진 것입니다. 기존 블록체인은 특정 기능(예: 결제 또는 DApp 실행)을 염두에 두고 설계되었으며, 일정 기간 운영 후 상위 계층 프로토콜이 자체적으로 적응하기를 바랍니다. 그러나 인터넷의 역사를 읽어보면 오늘날 인터넷의 프로토콜 계층화는 이런 방식으로 패치된 것이 아니라 과거의 경험을 흡수한 후에 이루어졌음을 알 수 있습니다. 그렇기 때문에 블록체인은 당연히 레이어 1이 아니며, 레이어 1을 설계해야 합니다.

Layer 1이 무엇에 집중해야 하는지 파악하려면 먼저 상위 계층 프로토콜과의 차이점을 파악해야 합니다. 레이어 2의 기원은 퍼블릭 체인(여기서는 무허가형 블록체인)의 성능이 불충분하고 전체 암호화 경제의 요구를 충족시키기 위해 확장하기 어렵다는 우리의 발견과 관련이 있습니다. 결제 채널, 플라즈마 등 블록체인으로 확보할 수 있는 2가지 프로토콜

이러한 프로토콜의 공통 기능은 성능을 대가로 합의 범위를 희생한다는 것입니다. 퍼블릭 체인의 가장 놀라운 점은 개방형 네트워크를 통해 전 세계를 망라하는 중단 없는 서비스를 제공한다는 것인데, 이는 글로벌 합의와 낮은 성능을 의미합니다.

이 문제를 해결하는 가장 좋은 방법은 합의 범위는 작지만 성능은 더 좋은 상위 계층 프로토콜로 대부분의 트랜잭션을 전송하고 상위 계층 프로토콜의 참가자가 항상 블록체인으로 돌아와 문제를 해결할 수 있도록 하는 것입니다. 그들이 불만족할 때 비용은 약간의 시간 비용일 뿐입니다.

보조 제목

상태가 무엇입니까

블록체인 네트워크의 모든 전체 노드는 일정 기간 동안 네트워크에서 실행된 후 로컬 스토리지에 일부 데이터를 남깁니다.이력과 현재에 따라 두 가지 범주로 나눌 수 있습니다.

블록체인 네트워크의 모든 전체 노드는 일정 기간 동안 네트워크에서 실행된 후 로컬 스토리지에 일부 데이터를 남깁니다.이력과 현재에 따라 두 가지 범주로 나눌 수 있습니다.

히스토리: 블록 데이터와 트랜잭션 데이터 모두 히스토리이며, 히스토리는 제네시스에서 현재 상태까지의 경로입니다.

상태(즉, 지금): 제네시스부터 현재 높이까지 모든 블록과 트랜잭션을 처리한 후 노드가 형성한 최종 결과. 상태는 블록 추가와 함께 항상 변화하고 있으며 트랜잭션이 변화의 원인입니다.

합의 프로토콜의 역할은 일련의 메시지 교환을 통해 각 노드가 보는 현재 상태가 동일하도록 하는 것이며, 이 목표를 달성하는 방법은 각 노드가 보는 이력이 동일하도록 하는 것입니다. 히스토리가 같으면(즉, 모든 트랜잭션의 순서가 같다면), 트랜잭션을 처리하는 방식은 동일하고(동일한 결정론적 가상 머신에서 트랜잭션을 실행), 마지막에 보이는 현재 상태 는 ~와 마찬가지로. 우리가 "블록체인은 불변"이라고 말할 때, 이는 블록체인의 역사가 변조될 수 없다는 것을 의미하며, 반대로 상태는 항상 변화하고 있습니다.

보조 제목

예: 비트코인의 역사와 상태

비트코인의 상태는 비트코인 ​​원장의 현재 상태를 나타냅니다. 비트코인의 상태는 UTXO(아직 사용되지 않은 트랜잭션 출력)로 구성되며 각 UTXO는 일정량의 비트코인을 나타내며 각 UTXO에는 이 UTXO의 소유자가 누구인지 기록하기 위해 이름(scriptPubkey)이 기록됩니다. 비유하자면 비트코인의 현재 상태는 각각 소유자의 이름이 새겨진 금화로 가득 찬 가방입니다.

비트코인의 역사는 일련의 트랜잭션으로 구성되며 트랜잭션 내의 주요 구조는 입력과 출력입니다. 트랜잭션은 현재 상태에 포함된 일부 UTXO(트랜잭션 입력에 의해 참조되는 것)를 소비된 것으로 표시하고 UTXO 집합에서 제거한 다음 일부 새로운 UTXO(이 트랜잭션의 출력)를 UTXO 집합 이동에 추가하여 상태를 변경합니다.

비트코인 트랜잭션의 아웃풋(TXO, Transaction Output)이 정확히 위에서 언급한 UTXO이고, UTXO는 단지 특별한 단계(아직 소비되지 않은)의 TXO임을 알 수 있습니다. 비트코인(UTXO)의 상태를 구성하는 구성 요소는 트랜잭션(TXO)을 구성하는 구성 요소이기도 하기 때문입니다.

따라서 비트코인은 훌륭한 속성을 가지고 있습니다. 언제든지 상태는 기록의 하위 집합이며 기록과 상태에 포함된 데이터 유형은 동일한 차원입니다. 트랜잭션의 히스토리(패키징된 모든 트랜잭션의 집합, 즉, 생성된 모든 TXO의 집합)는 상태의 히스토리(각 블록에 해당하는 UTXO의 집합, 생성된 모든 TXO의 집합이기도 함)이며, Bitcoin의 역사는 트랜잭션만 포함합니다.

보조 제목

또 다른 예: 이더리움의 역사와 상태

"세계의 상태"라고도 하는 이더리움의 상태는 이더리움 원장의 현재 상태를 나타냅니다. 이더리움의 상태는 계정으로 구성된 머클 트리입니다.(계정은 나뭇잎입니다.) 계정은 잔액(일정량의 이더를 나타냄)뿐만 아니라 계약 데이터(예: 암호화된 각 고양이의 데이터)도 기록합니다. 이더리움의 상태는 큰 원장이라고 볼 수 있는데, 원장의 첫 번째 열은 이름, 두 번째 열은 잔액, 세 번째 열은 계약 데이터입니다.

이더리움의 역사도 트랜잭션으로 구성되어 있으며 트랜잭션 내부의 주요 구조는 다음과 같습니다.

to: 트랜잭션 발신자를 나타내는 다른 계정

값: 거래에 의해 운반되는 이더의 양

데이터: 트랜잭션에 의해 전달되는 모든 정보

트랜잭션이 상태를 변경하는 방식은 EVM이 트랜잭션이 전송되는 대상 계정을 찾는 것입니다.

1. 거래 금액에 따라 대상 계정의 새로운 잔액을 계산합니다.

2. 대상 계정의 스마트 계약에 매개 변수로 거래에 포함된 데이터를 전달하고 스마트 계약의 논리를 실행하며 작업 중에 계정의 내부 상태를 수정하여 새로운 상태를 생성할 수 있습니다.

3. 새 리프를 구성하여 새 상태를 저장하고 상태 Merkle 트리를 업데이트합니다.

Ethereum의 역사와 거래 구조는 Bitcoin과 매우 다르다는 것을 알 수 있습니다. 이더리움의 상태는 계정으로 구성되고 거래는 계정 변경을 유발하는 정보로 구성됩니다 상태와 거래는 완전히 다른 유형의 데이터를 기록합니다 둘 사이에 상위 집합과 하위 집합 관계가 없습니다 기록과 상태에는 다음과 같은 데이터 유형이 포함됩니다 2차원적이며 트랜잭션 히스토리의 크기와 상태의 크기 사이에 필요한 연결이 없습니다.

트랜잭션이 상태를 수정한 후 새로운 상태(그림에서 실선 상자의 잎)를 생성할 뿐만 아니라 이전 상태(그림의 점선 상자의 잎)를 기록 상태로 남겨둡니다. 이더리움의 역사는 트랜잭션을 포함할 뿐만 아니라 역사적 상태도 포함합니다.

히스토리와 상태는 서로 다른 차원에 속하기 때문에 이더리움 블록 헤더는 트랜잭션의 머클 루트를 포함할 뿐만 아니라 명시적으로 상태의 머클 루트를 포함해야 합니다.

Ethereum의 모든 블록과 모든 계정은 계속해서 노드의 저장 공간을 차지합니다. 이더리움 노드는 동기화할 때 여러 모드가 있습니다.아카이브 모드에서는 거래 내역 및 내역 상태를 포함하여 모든 내역 및 상태가 보존됩니다.모든 데이터의 총 크기는 2TB를 초과합니다.기본 모드에서는 내역 상태가 잘립니다. 과거 트랜잭션과 현재 상태만 로컬에 보관되며 총 데이터는 약 170G이며 이 중 트랜잭션 기록 크기는 150G, 현재 상태 크기는 10G입니다.

이더리움의 모든 오버헤드 관리는 가스 청구 모델로 통일되며 트랜잭션의 크기는 해당 가스를 소비해야 하며 각 EVM 명령에서 소비하는 가스는 컴퓨팅 오버헤드뿐만 아니라 스토리지 오버헤드도 고려합니다. 각 블록의 가스 제한을 통해 역사와 상태의 성장 속도를 간접적으로 제한합니다.

ps. 이더리움의 "블록체인 크기"가 1T를 넘어섰다는 것이 흔한 오해입니다. 위의 분석에서 우리는 "블록체인 크기"가 매우 모호한 정의라는 것을 알 수 있습니다. 과거 상태를 계산하면 실제로 초과하지만 모든 노드에 대해 과거 상태를 삭제하는 데 문제가 없습니다. 제네시스와 트랜잭션 히스토리가 있기 때문에 언제든지 히스토리 상태를 다시 계산할 수 있습니다(계산에 필요한 시간에 관계없이).

진정으로 의미 있는 데이터는 풀노드에 필요한 데이터의 크기 비트코인은 200G, 이더리움은 170G 기본적으로 둘은 동일하며 평균적으로 구성된 클라우드 호스트에 설치할 수 있다 감소는 스토리지 증가로 인한 것이 아니다 (근본 원인은 동기화 시 계산 오버헤드입니다).

보조 제목

(스토리지) 커먼즈의 비극: 커먼즈의 비극의 블록체인 버전

공유지의 비극은 제한된 공유 자원을 무제한으로 사용하는 사람들이 과소비하는 상황을 말합니다. 기록과 상태를 보존하기 위해 블록체인 노드가 지불하는 스토리지는 바로 그러한 공유 리소스입니다.

트랜잭션, CPU, 스토리지 및 네트워크 대역폭을 처리하기 위해 블록체인 노드에서 사용하는 세 가지 유형의 리소스가 있습니다. CPU와 대역폭은 모두 각 블록에서 새로 고칠 리소스입니다.각 블록 간격에서 동일한 양의 CPU와 대역폭을 사용할 수 있다고 생각할 수 있습니다.이전 블록에서 소비한 CPU와 대역폭은 다음 블록을 허용하지 않습니다. 블록에 사용 가능한 CPU 및 대역폭. 새로 고칠 수 있는 리소스의 경우 거래 수수료의 일회성 지불을 통해 노드를 보상할 수 있습니다(수수료와 계산 복잡성 및 거래 크기 간의 상관 관계는 RFC0015부록 참조).

스토리지는 CPU 및 대역폭과 달리 점유된 리소스이며 블록에 점유된 스토리지는 사용자가 적극적으로 해제하지 않는 한 후속 블록에서 다른 사용자가 사용할 수 없습니다. 노드는 스토리지 비용을 지속적으로 지불해야 하지만 사용자는 스토리지 비용을 지속적으로 지불할 필요가 없습니다(트랜잭션 수수료는 한 번만 지불하면 됨을 기억하십시오).

사용자는 블록체인에 데이터를 쓸 때 약간의 비용만 지불하면 Amazon S3를 초과하는 가용성을 가진 저장소를 영구적으로 사용할 수 있으며 무한한 영구 저장소 비용은 블록체인 네트워크의 모든 전체 노드에서 부담해야 합니다.

이더리움에는 다양한 DApp이 존재하기 때문에 (스토리지) 커먼즈의 비극은 상대적으로 더 심각합니다. 예를 들어, 블록 5700001(2018년 5월 30일) 당시 가장 많이 사용된 5개의 계약은 다음과 같습니다.

• EtherDelta,     5.09%

• IDEX,     4.17%

• CryptoKitties,     3.05%

• ENS,     1.92%

• EOS Sale, 1.73%

더 흥미로운 것은 마지막 EOS Sale입니다. EOS 크라우드 펀딩이 완료되고 EOS 토큰이 EOS 체인에 유통되었지만 EOS 크라우드 펀딩 기록은 이더리움 노드에 영원히 남아 전체 이더리움 노드의 스토리지 리소스를 소비합니다.

상태 폭발

상태 폭발

하드웨어의 평균 수준 향상이 역사와 상태의 축적 속도를 초과할 수 있습니까? 내 대답은 가능성이 거의 없습니다.

하드웨어의 평균 수준 향상이 역사와 상태의 축적 속도를 초과할 수 있습니까? 내 대답은 가능성이 거의 없습니다.

이 그래프에서 우리는 이더리움 네트워크가 발전함에 따라 축적되는 상태 데이터의 양이 기하급수적으로 증가한다는 것을 알 수 있습니다. 비트코인의 상태 데이터가 0에서 3G까지 누적되는 데 10년이 걸렸고, 이더리움의 상태 데이터가 0에서 10G까지 누적되는 데 4년이 걸렸습니다. 틈새 기술 사례 성장률.

확장성 문제를 해결하면 블록체인이 실제로 대량 채택되고 DApp 및 사용자 수가 폭발적으로 증가합니다. 블록체인 히스토리 및 상태 데이터는 어느 속도로 축적됩니까?

이것은 확장성 문제를 해결한 후에 매우 명백하기 때문에 사후 확장성 문제로 분류하는 상태 폭발 문제입니다. 우리는 라이선스 체인 시나리오에서 작업할 때 이 문제를 처음 발견했습니다. 라이선스 체인의 성능이 퍼블릭 체인의 성능보다 훨씬 높고 확장성 이후 단계에 있기 때문입니다.

과거 데이터의 축적은 상대적으로 다루기 쉬우며, 미래에는 탈중앙화 체크포인트나 영지식증명 등의 기술로 압축할 수 있으며, 그 전에는 풀노드가 직접 역사를 버리고 정상적으로 운영할 수도 있다. 상태 데이터의 축적은 전체 노드 운영에 필요한 데이터이기 때문에 훨씬 번거롭습니다.

많은 블록체인 프로젝트에서 이 문제를 확인하고 몇 가지 솔루션을 제안했습니다. EOS RAM은 상태 폭발 문제를 해결하기 위한 유용한 시도입니다. RAM은 슈퍼 노드 서버에서 사용할 수 있는 메모리 리소스를 나타내며 계정, 계약 상태 또는 코드인지 여부에 관계없이 실행하려면 일정량의 RAM을 점유해야 합니다.

RAM의 설계도 문제가 많습니다 내장된 거래 시장을 통해 구매해야 합니다 양도할 수 없고 임대할 수 없습니다 계약 실행 시 단기 메모리 요구 사항과 장기 저장 요구 사항을 혼합합니다 컨트랙트 상태의 총 RAM 용량이 설정되며 명확한 규칙은 없으며 합의 공간 비용보다 슈퍼노드가 감당할 수 있는 하드웨어 구성에 더 의존합니다.

이더리움 커뮤니티도 이 문제를 보고 저장소 임대 솔루션을 제안했습니다: 사용자는 저장소 자원을 사용하기 위해 미리 임대료를 지불해야 합니다. 저장소 자원을 점유하면 이 임대료가 계속 소비됩니다. 점유 시간이 길수록 임대료는 사용자는 더 많은 비용을 지불해야 합니다. Storage Rent 솔루션에는 두 가지 문제가 있습니다.

1. 선불 임대료는 언젠가 소진될 예정인데, 이때 입주 상황은 어떻게 처리되나요? 이 문제를 해결하기 위해 Storage Rent는 설계의 복잡성을 증가시키고 스마트 계약의 불변성을 크게 줄이고 사용자 경험에 문제를 일으키는 복구와 같은 메커니즘이 필요합니다.

2. 이더리움의 상태 모델은 퍼스트 클래스 상태가 아닌 공유 상태 모델입니다. ERC20Token을 예로 들면 모든 사용자 자산 기록은 단일 ERC20 계약 저장소에 저장됩니다.이 경우 임대료는 누가 지불해야 합니까?

상태 폭발 문제를 해결하는 것도 Nervos CKB의 설계 목표 중 하나이므로 완전히 다르고 더 급진적인 변화 경로를 택했습니다. 즉, Nervos CKB에서 토큰은 저장 공간의 단위를 나타냅니다.경제 모델의 설계를 통해 우리는 세계 상태의 크기를 제한하고 시장 수단을 사용하여 상태 저장의 공급과 수요를 조정하며 지속적으로 제공합니다. 추가 발행 설계를 통해 국가를 점유하는 사용자 수수료는 장기적인 보안과 지속적인 안정성을 달성하기 위해 생태계의 모든 당사자의 이익을 조정하는 데 사용됩니다.