만약에레이어 1의 초점은 계산이 아닌 상태여야 합니다.보조 제목

상태

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

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

• 상태(즉, 지금) - 노드가 Genesis에서 처리를 완료했습니다.
  

현재 높이까지의 모든 블록 및 트랜잭션 후에 형성된 최종 결과입니다. 상태는 블록 추가와 함께 항상 변화하고 있으며 트랜잭션이 변화의 원인입니다.

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

흥미롭게도 서로 다른 블록체인은 서로 다른 방식으로 기록과 상태를 저장하며, 그 차이로 인해 서로 다른 블록체인이 고유한 특성을 형성합니다. 이 글에서 논의하는 주제는 상태이고, 상태에 영향을 미치는 과거 데이터는 주로 트랜잭션(블록 헤더가 아닌)이기 때문에, 역사에 대한 다음 논의는거래에 집중보조 제목

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

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

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

비트코인 트랜잭션의 아웃풋(TXO, Transaction Output)이 정확히 위에서 언급한 UTXO이고, UTXO는 단지 특별한 단계(아직 소비되지 않은)의 TXO임을 알 수 있습니다. 비트코인(UTXO)의 상태를 구성하는 구성 요소는 트랜잭션(TXO)을 구성하는 구성 요소이기도 하기 때문입니다. 따라서 Bitcoin에는 다음과 같은 놀라운 속성이 있습니다.어떤 순간의 상태는 역사의 부분 집합입니다., 기록 및 상태에 포함된 데이터 유형은 동일한 차원입니다.트랜잭션의 히스토리(패키징된 모든 트랜잭션의 집합, 즉, 생성된 모든 TXO의 집합)는 상태의 히스토리(각 블록에 해당하는 UTXO의 집합, 생성된 모든 TXO의 집합이기도 함)이며, Bitcoin의 역사는 트랜잭션만 포함합니다.

비트코인 네트워크에서 각 블록과 각 UTXO는 계속해서 노드의 저장 공간을 차지합니다. 현재비트코인 전체 히스토리의 크기(모든 블록을 합한 크기)는 약 200G입니다.,그리고상태의 크기는 약 3G에 불과합니다(약 5천만 UTXO로 구성).보조 제목

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

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

Ethereum의 역사도 트랜잭션으로 구성되며 트랜잭션 내부의 주요 구조는 다음과 같습니다.

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

• 가치 - 거래에 의해 운반되는 에테르의 양

• 데이터 - 트랜잭션에 의해 전달되는 임의의 정보

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

1. 거래 금액에 따라 대상 계정의 새로운 잔액을 계산합니다.
2. 대상 계정의 스마트 계약에 매개 변수로 거래에 포함된 데이터를 전달하고 스마트 계약의 논리를 실행하며 작업 중에 계정의 내부 상태를 수정하여 새로운 상태를 생성할 수 있습니다.
3. 새 리프를 구성하여 새 상태를 저장하고 상태 Merkle 트리를 업데이트합니다.

Ethereum의 역사와 거래 구조는 Bitcoin과 매우 다르다는 것을 알 수 있습니다. 이더리움의 상태는 계정으로 구성되고 트랜잭션은 계정 변경을 유발하는 정보로 구성됩니다.상태와 트랜잭션은 완전히 다른 유형의 데이터를 기록합니다.이 둘 사이에는 상위 집합과 하위 집합 관계가 없습니다.기록 및 상태에 포함된 데이터 유형은 2차원적입니다., 트랜잭션 기록 크기와 상태 크기 사이에 필요한 관계가 없습니다. 트랜잭션이 상태를 수정한 후 새로운 상태(그림에서 실선 상자의 잎)를 생성할 뿐만 아니라 이전 상태(그림의 점선 상자의 잎)를 기록 상태로 남겨둡니다. 이더리움의 역사는 트랜잭션을 포함할 뿐만 아니라 역사적 상태도 포함합니다. 히스토리와 상태는 서로 다른 차원에 속하기 때문에 이더리움 블록 헤더는 트랜잭션의 머클 루트를 포함할 뿐만 아니라 명시적으로 상태의 머클 루트를 포함해야 합니다. (생각하는 질문: EOS는 이더리움과 유사한 계정 모델을 사용하지만 블록 헤더에 상태 Merkle Tree Root를 포함하지 않습니다. 이것이 좋은가요 나쁜가요?)

Ethereum의 모든 블록과 모든 계정은 계속해서 노드의 저장 공간을 차지합니다. Ethereum 노드는 동기화할 때 여러 모드가 있습니다.아카이브 모드에서는 모든 기록과 상태가 보존됩니다.기록에는 과거 트랜잭션과 과거 상태가 포함됩니다.모든 데이터를 합친 크기가 2TB를 초과합니다.;기본 모드에서는 과거 상태가 정리되고 과거 트랜잭션과 현재 상태만 로컬에 유지됩니다.모든 데이터는 약 170G까지 추가됩니다.,안에트랜잭션 히스토리 크기는 150G이고 현재 상태 크기는 10G입니다.. 이더리움의 모든 오버헤드 관리는 가스 청구 모델로 통일되며 트랜잭션의 크기는 해당 가스를 소비해야 하며 각 EVM 명령에서 소비하는 가스는 컴퓨팅 오버헤드뿐만 아니라 스토리지 오버헤드도 고려합니다. 각 블록의 가스 제한을 통해 역사와 상태의 성장 속도를 간접적으로 제한합니다.

ps. 이더리움의 "블록체인 크기"가 1T를 넘어섰다는 것이 흔한 오해입니다. 위의 분석에서 우리는 "블록체인 크기"가 매우 모호한 정의라는 것을 알 수 있습니다. 과거 상태가 포함되면 초과합니다. 그러나 모든 노드에 대해 과거 상태를 삭제하는 데 문제가 없습니다. 제네시스와 트랜잭션 히스토리가 있기 때문에 언제든지 히스토리 상태를 다시 계산할 수 있습니다(계산에 소요되는 시간에 관계없이). 정말 의미 있는 데이터는 풀노드에 필요한 데이터의 크기인데, 비트코인은 200G, 이더리움은 170G, 둘은 기본적으로 같고 평균적으로 구성된 클라우드 호스트에 설치할 수 있다. 스토리지 증가(근본 원인은 동기화 중 계산 오버헤드이며 여기에서 확장되지 않음). 이더리움의 히스토리 길이(현재 블록의 타임스탬프에서 제네시스의 타임스탬프를 뺀 값)가 비트코인의 절반도 안 되는 것을 감안하면 이더리움의 히스토리와 상태 크기가 더 빠르게 성장하는 것을 알 수 있다.

(스토리지) 커먼즈의 비극: 커먼즈의 비극의 블록체인 버전
공유지의 비극이란 유한한 공유 자원을 아무런 제약 없이 사람들이 과소비하는 상황을 말한다. 기록과 상태를 보존하기 위해 블록체인 노드가 지불하는 스토리지는 바로 그러한 공유 리소스입니다.

트랜잭션, CPU, 스토리지 및 네트워크 대역폭을 처리하기 위해 블록체인 노드에서 사용하는 세 가지 유형의 리소스가 있습니다. CPU와 대역폭은 각 블록에서 새로 고칠 리소스입니다.각 블록 간격에서 사용 가능한 CPU와 대역폭의 양은 동일하다고 생각할 수 있습니다.이전 블록에서 소비된 CPU와 대역폭은 다음 블록을 만들지 않습니다.더 적은 CPU와 청크에 사용 가능한 대역폭. 새로 고칠 수 있는 리소스의 경우 일회성 트랜잭션 수수료로 노드를 보상할 수 있습니다.

CPU 및 대역폭과 달리 스토리지는 점유된 리소스이며 블록에 점유된 스토리지는 사용자가 적극적으로 해제하지 않는 한 후속 블록에서 다른 사용자가 사용할 수 없습니다. 노드는 스토리지 비용을 지속적으로 지불해야 하지만 사용자는 스토리지 비용을 지속적으로 지불할 필요가 없습니다(트랜잭션 수수료는 한 번만 지불하면 됨을 기억하십시오). 사용자는 블록체인에 데이터를 쓸 때 약간의 비용만 지불하면 되며 가용성이 Amazon S3를 초과하는 스토리지를 영구적으로 사용할 수 있으며 무한 영구 스토리지 비용은 블록체인 네트워크의 모든 전체 노드에서 부담해야 합니다.

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

1.EtherDelta, 5.09%
2.IDEX, 4.17%
3.CryptoKitties, 3.05%
4.ENS, 1.92%
5.EOS Sale, 1.73%

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

관리가 없으면 의도적으로 또는 의도하지 않게 블록체인의 스토리지 리소스가 남용될 수 있음을 알 수 있습니다. 잘 설계된 경제 모델에서 사용자는 스토리지 점유 비용을 부담해야 합니다.보조 제목。

상태 폭발

과거 데이터와 상태 데이터 모두 스토리지 리소스를 차지합니다. 비트코인과 이더리움에 대한 위의 분석을 통해(다른 블록체인의 상태 모델은 기본적으로 둘 중 하나로 요약될 수 있음) 역사와 상태의 성장을 관리하지만 전체 역사와 상태에 대한 통제가 없음을 알 수 있습니다. 크기와 이러한 데이터는 끝없이 계속 축적되어 전체 노드를 실행하는 데 필요한 스토리지 리소스가 점점 더 커집니다. 전체 노드의 운영 임계값을 높이면 네트워크가 점점 더 분산화되지 않을 것입니다. 이는 우리가 보고 싶지 않은 것입니다.

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

이 그래프에서 우리는 이더리움 네트워크가 발전함에 따라 축적되는 상태 데이터의 양이 기하급수적으로 증가한다는 것을 알 수 있습니다. 비트코인의 상태 데이터가 0에서 3G까지 누적되는 데 10년이 걸렸고, 이더리움의 상태 데이터가 0에서 10G까지 누적되는 데 4년이 걸렸습니다. 틈새 기술 사례 성장률.확장성 문제를 해결하고 블록체인이 실제로 대량 채택되고 DApp과 사용자 수가 폭발적으로 증가할 때 블록체인 히스토리 및 상태 데이터는 어느 속도로 축적됩니까?

이것은 확장성 문제를 해결한 후에 매우 명백하기 때문에 사후 확장성 문제로 분류하는 상태 폭발 문제입니다. 라이선스 체인 시나리오를 구현했을 때 이 문제를 처음 발견했습니다.허가형 체인의 성능은 퍼블릭 체인보다 훨씬 높습니다., 사후 확장성 단계에 있습니다. (생각하는 질문: 권한 체인이 상태 폭발 문제를 어떻게 해결합니까?)

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

많은 블록체인 프로젝트에서 이 문제를 확인하고 몇 가지 솔루션을 제안했습니다. EOS RAM은 상태 폭증 문제를 해결하기 위한 유용한 시도입니다. RAM은 슈퍼 노드 서버가 사용할 수 있는 메모리 리소스를 나타내며 계정, 계약 상태 또는 코드인지 여부에 관계없이 실행하려면 일정량의 RAM을 점유해야 합니다. RAM의 설계도 문제가 많습니다 내장된 거래 시장을 통해 구매해야 합니다 양도할 수 없고 임대할 수 없습니다 계약 실행 시 단기 메모리 요구 사항과 장기 저장 요구 사항을 혼합합니다 계약 상태의 총 RAM 양은 지정되지 않으며 결정된 규칙은 합의 공간의 비용보다는 슈퍼 ​​노드가 견딜 수 있는 하드웨어 구성에 더 의존합니다.

이더리움 커뮤니티도 이 문제를 보고 물었습니다.스토리지렌트의 솔루션: 사용자는 저장소 자원을 사용하기 위해 미리 임대료를 지불해야 하며, 저장소 자원을 점유하면 이 임대료를 계속 소비하게 되며, 점유 시간이 길어질수록 사용자는 더 많은 임대료를 지불해야 합니다. 저장소 임대료 체계에는 두 가지 문제가 있습니다.

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

2. 이더리움의 상태 모델은 공유 상태의 모델이지,First-class State. ERC20 토큰을 예로 들면 모든 사용자 자산 기록은 하나의 ERC20 계약 저장소에 저장됩니다.이 경우 임대료는 누가 지불해야 합니까?

원본 링크:

원본 링크:https://talk.nervos.org/t/top...