ReGenesis로 이더리움 네트워크를 개선하는 방법 알아보기

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

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

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

DeFi 애플리케이션에 잠긴 자금의 양은 15억 달러를 초과했으며 거의 ​​매일 새로운 dApp이 발표됩니다. 이 속도에서 Ethereum은 너무 성공적이어서 죽을 수 있습니다. 인프라 계층에 관한 한 무한 상태 성장은 큰 문제입니다.

며칠 전 Alexey는 EthResearch 포럼에 ReGenesis라는 흥미로운 아이디어를 제안하는 기사를 게시했습니다.

이 아이디어는 비교적 간단하고 언뜻 급진적으로 보일 수 있습니다. 주기적으로(예: 100만 블록마다) 로컬에 저장된 모든 상태를 삭제하고 최신 블록의 루트 해시를 유지하고 다시 100만 블록 후에 상태 구축을 시작합니다. , 다음 상태 재설정이 수행됩니다.

이미지 설명

-ReGenesis : N 블록마다 상태를 재설정합니다. 상태가 커짐에 따라 다음 ReGenesis가 시작될 때까지 더 적은 증명이 필요합니다.

이 아이디어가 실현 가능하고 조사할 가치가 있는 이유를 이해하려면 몇 가지 배경과 설명이 필요합니다.

이것이 이 기사의 내용입니다.

현재 상황

1. 중앙 집중식 상태 저장

Ethereum에서 거래를 보내는 것은 매우 쉽습니다. 상태 데이터가 필요하지 않습니다. 트랜잭션 발신자는 상태를 저장할 인센티브가 없습니다.

당신(채굴자 또는 거래소)이 인프라 노드를 실행하고 있다면 트랜잭션을 검증하고 브로드캐스트하는 데 필요한 모든 상태가 있는지 확인해야 합니다. 광부라면 더 많은 상태가 필요합니다.

따라서 현재 상태 스토리지는 대형 엔터티(Infura, 대형 채굴자, 거래소 등)가 운영하는 인프라 노드에 집중되어 있습니다.

2. 국가는 계속해서 무한히 성장한다

보도 시간(6월 29일) 현재 Turbo-Geth 클라이언트의 "현재 상태"는 약 40GB이며 계속 증가하고 있습니다.

여기서 문제는 상태 크기 자체가 아니라 무제한 상태 성장입니다. 물론 SSD 용량이 블록체인 상태보다 빠르게 증가하기를 기도할 수도 있습니다.

우리는 지금까지 운이 좋았지만 운만으로는 장기적인 해결책이 아닙니다.

3. Stateless Ethereum은 Gas의 가격을 다시 책정하기 어렵습니다.

상태 비저장 이더리움 프로젝트의 경우 블록 증인 가격 책정이 매우 어렵습니다. 이러한 증인은 채굴자에 의해 생성되며 트랜잭션 발신자가 트랜잭션을 보낼 때 블록 증인의 크기를 예측하기 어렵습니다.

따라서 기존 스마트 컨트랙트에 영향을 주지 않으면서 스마트 컨트랙트 행위를 통해 증인 가격을 추측할 수 있는 방법을 찾아야 합니다.

이미 Oil과 같은 몇 가지 제안이 있지만 이것은 정말 까다로운 문제입니다.

ReGenesis 이후 트랜잭션을 실행하는 방법

자, 이제 우리 모두는 모든 현재 상태를 0으로 만들기 위해 루트 해시만 유지된다는 것을 알고 있습니다. 데이터 양이 40GB에서 32바이트로 줄었습니다.

이때 상태 비저장 이더리움이 유용합니다. 트랜잭션을 실행할 수 있으려면 증인을 제공해야 합니다. 증인에는 사용된 계정, 코드 및 계약 저장소 콘텐츠, 루트 해시를 확인하는 데 사용할 수 있는 Merkle 증명이 포함됩니다(여기를 클릭하여 증인 및 상태 비저장 이더리움에 대해 자세히 알아보십시오).

그러나 ReGenesis와 Stateless Ethereum에는 한 가지 차이점이 있습니다. 차이점을 설명하기 전에 명시적 상태와 암시적 상태라는 두 가지 용어를 소개하고 싶습니다.

geth 노드를 실행 중이라고 가정합니다. 피어 노드가 새 블록 N을 보낼 때마다 노드는 해당 블록 내의 모든 트랜잭션을 확인하는 데 필요한 상태 데이터가 이미 있고 블록 N-1을 동기화했다고 가정합니다.

- 현재 이더리움: 두 노드 모두 필요한 상태가 모두 있다고 가정 -

이것은 100% 암시적 상태입니다. 피어는 이미 상태가 있다고 가정하므로 블록에 상태를 추가하지 않습니다.

상태 비저장 이더리움에서 노드를 실행할 때 피어 노드는 새 블록 N을 보내고 어떤 상황에서도 암시적 상태가 없다고 생각합니다. 블록 N을 블록 N으로 실행하는 데 필요한 모든 것을 포장합니다. 이것은 블록 증인입니다.

이미지 설명

동료가 명시적인 상태를 보냅니다.

ReGenesis가 블록 10.000.000에서 시작한다고 가정해 보겠습니다. 현재 블록체인의 최상위에는 블록 10.001.000이 있습니다. 우리는 모든 ReGenesis 노드가 블록 10.000.000과 블록 10.001.000 사이의 모든 데이터의 암시적 상태를 가지고 있다고 생각할 수 있습니다. 이러한 블록에 사용된 모든 계정, 모든 저장소 항목 및 모든 계약은 이미 모든 노드에 저장되어 있으므로 블록 증인이 필요하지 않습니다. 이를 통해 준상태 비저장 동기화 실험에서 보았듯이 증인의 크기를 크게 줄일 수 있습니다.

이미지 설명

- ReGenesis: 블록 1은 Node 1이 부족한 정보를 제공합니다 -

• 이미지 설명

• - ReGenesis: 블록 1의 상태를 노드 1의 암시적 상태로 병합 -

• 트랜잭션 발신자로서 현재 블록 높이가 10.001.000인 네트워크에 새 트랜잭션을 보내야 하는 경우 다음 단계를 수행해야 합니다.

• 원하는 거래를 생성하십시오.

암시적 상태에 포함되지 않은 항목에 대한 명시적 상태를 만들고 트랜잭션 증인으로 패키징합니다(자세한 내용은 아래에서 설명).

좋아요.

증인과의 트랜잭션을 네트워크로 전송합니다.

잠깐, 트랜잭션 발신자가 ReGensis 이전 상태를 가지고 있어야 한다는 뜻인가요? !

좋아요.

ReGenesis가 시작된 후 트랜잭션을 보내려면 증인을 생성하기 위해 ReGenesis 이전 상태 정보가 필요할 수 있습니다.

그러나 대부분의 dApp의 경우 실제로 사용되는 소규모 계약 및 계정의 상태를 저장해야 합니다(물론 Merkle 증명 포함).

거래 증인

위에서 트랜잭션 증인이라는 용어를 언급한 것을 눈치채셨을 것입니다.

이미지 설명

- 결합된 블록 증인 -

이미지 설명

- 거래 증인 -

이미지 설명

- 블록 증인은 채굴자에 의해 생성됩니다. 복잡한 가스 가격 책정 메커니즘을 통해 보상해야 합니다.

트랜잭션 증인은 중요한 이점이 있습니다. 트랜잭션 발신자에 의해 생성되고 트랜잭션과 함께 전송됩니다. 따라서 거래 증인의 규모와 가격 책정 방법을 즉시 알 수 있습니다. EVM을 통해 가격을 재조정할 필요가 없습니다.

이미지 설명

- 거래 증인은 거래 발신자에 의해 생성되며 보상하기가 훨씬 쉽습니다 -

트랜잭션 증인 사용의 잠재적 위험은 데이터 복제입니다. 블록의 모든 거래가 동일한 두 계정에 의해 이루어진다고 가정하면 거래 감시에는 중복 데이터가 포함됩니다.

블록 증인은 채굴자에 의해 생성됩니다. 채굴자는 블록 내 트랜잭션의 정확한 순서를 알고 있으므로 블록 증인은 항상 최신 데이터를 포함합니다.

트랜잭션 증인은 트랜잭션 발신자로부터 옵니다. 따라서 트랜잭션 감시를 블록의 이전 트랜잭션에서 생성된 암시적 상태와 병합하는 스마트 병합 메커니즘이 있어야 합니다.

그러나 전체 ReGenesis 개념에는 트랜잭션 증인의 사용이 필요하므로 큰 문제는 아닙니다.

첫 번째 레벨 제목

트랜잭션 증인을 아직 사용할 수 없는 이유는 무엇입니까?

간단히 말해서 DSA(Dynamic State Access)와 악의적인 행위자가 거래를 선행할 가능성이 있기 때문입니다.

특히 상태 비저장 이더리움에서는 이 트랜잭션의 완전한 상태를 제공해야 하며 수신자는 상태가 없다고 가정합니다. 트랜잭션이 DSA를 사용하는 경우 코드가 읽는 스토리지 부분은 코드의 다른 부분에 있는 값에 따라 다릅니다.

이론적으로 이것은 DoS 공격을 유발할 수 있습니다.

Alice가 A를 포함하는 증명을 제공하면 Bob은 Alice의 트랜잭션이 패키지되기 전에 K를 변경할 수 있으므로 Alice의 트랜잭션이 실패합니다. Alice가 B를 포함하는 증명을 제공하면 Bob은 트릭을 반복할 수 있습니다.

물론 Alice는 A와 B를 포함하는 증명을 제공할 수 있지만 저장 주소가 uint64로 결정되는 경우 Alice는 공격을 방지하기 위해 증명에 완전한 상태를 포함해야 하지만 단순히 완전한 상태를 포함하는 것은 불가능합니다.

물론 이 공격은 이론적이다. 그러나 더 유사한 공격이 나타날 가능성이 있습니다. dApp이 보유하고 있는 많은 양의 자금을 감안할 때 우리는 어떤 것도 깨지 않도록 매우 주의해야 합니다.

첫 번째 레벨 제목

ReGenesis는 이 문제를 어떻게 완화합니까?

ReGenesis의 결정성은 노드가 얼마나 많은 상태를 가지고 있는지 결정하는 데 도움이 될 수 있습니다. 노드에 있다고 확신하는 상태의 경우 증명이 필요하지 않습니다.

이 문제를 완화하기 위해 state가 부족하여 트랜잭션이 성공하든 실패하든 우리가 제공하는 증명이 state에 포함되도록 합니다.

Alice의 트랜잭션은 실패했지만 트랜잭션은 경로 A에 필요한 모든 증명을 노드의 암시적 상태에 추가했습니다.

결론적으로

이제 Alice는 이 트랜잭션을 재전송하여 경로 B에 필요한 증명을 제공할 수 있습니다. Bob은 더 이상 K를 변경하여 Alice의 트랜잭션을 차단할 수 없습니다. 트랜잭션이 경로 A를 선택하도록 K를 변경하더라도 너무 늦을 것입니다. 경로 A에서 요구하는 증명은 이미 노드의 암시적 상태에 포함되어 있으므로 트랜잭션이 수행되지 않습니다. 모든 증거를 노드로 보낼 수 있습니다. 트랜잭션이 경로 B로 전달되면 B가 필요로 하는 증명을 정확하게 갖게 됩니다.

• 첫 번째 레벨 제목

• 결론적으로

• 마지막으로 ReGenesis의 비전과 요점을 빠르게 요약해 보겠습니다.

• N 블록이 생성될 때마다 모든 상태를 지우고 루트 해시만 유지합니다.

• ReGenesis 시작 빈도는 너무 높지 않아야 하며, 100만 블록마다, 천만 블록마다 등으로 설정할 수 있습니다.

• 트랜잭션 발신자는 명시적인 상태를 제공해야 합니다(트랜잭션 증인으로).

• 트랜잭션 발신자는 트랜잭션 증인의 크기에 따라 가스 요금을 지불합니다.

이를 위해 거래 발신자는 관심 있는 계약/계정의 ReGenesis 이전 상태를 보존해야 합니다.

• 불충분한 명시적 상태로 인해 트랜잭션이 실패하는 경우 트랜잭션에서 제공하는 증명을 암시적 상태에 추가하여 다음에 트랜잭션을 보낼 때 동일한 증명을 제공할 필요가 없도록 합니다.

• 트랜잭션 증명의 명시적 상태는 스마트 병합 메커니즘을 통해 블록에서 이전에 실행된 트랜잭션에 의해 생성된 암시적 상태와 병합됩니다.

• 거시적 관점에서 볼 때 ReGenesis 솔루션은 다음과 같은 이점이 있습니다.

트랜잭션 발신자와 인프라 노드 간의 인센티브 균형을 변경하여 상태 저장의 분산을 개선합니다.