Ethereum 스토리지에 대한 분할 가격 및 이중 트랙 EIP1559

特邀专栏作者

2021-04-17 06:09

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

이더리움 상태 모델의 가장 큰 문제는 평균 상태 성장과 최악의 상태 성장 사이의 큰 차이입니다. .

이더리움 상태 모델의 가장 큰 문제는 평균 상태 성장과 최악의 상태 성장 사이의 큰 차이입니다.

이 기사는 Ethereum Researcher Forum에서 Vitalik이 제안한 최신 토론으로, Ethereum 연구 과학자 Barnabé Monnot이 제안한 EIP1559의 실제 구현에 대한 아이디어를 재구성한 것입니다.

다음은 원문을 번역한 것으로 팀에서 일부 단어에 주석을 달고 일부를 삭제했습니다.

저자: 비탈릭 부레린

편집: Baiplan 팀

초기에 유사한 아이디어를 제안한 @barnabe에게 특별히 감사드립니다.

리소스 가격 책정에 대한 이전 입장 보고서에서 자세히 논의한 것처럼 이더리움의 가스는 실제로 세 가지 다른 리소스에 대해 지불합니다.

1. 대역폭(다운로드가 필요한 거래 데이터)

2. 계산(트랜잭션을 확인하고 실행하는 데 걸리는 시간)

3. 저장(이력이지만 더 중요한 것은 계정 잔액, 논스, 계약 코드, 계약 저장과 같은 진술문)

Plan Bai는 "자원 가격 책정에 대한 입장 문서"는 Vitalik이 수학적 계산을 통해 해당 가격 책정 방법을 추론하는 블록체인 자원 가격 책정 초안입니다.

초안에는 가격 및 수량, 사회적 비용 곡선, 1차 및 2차 경매, 조정 가능한 수수료 일정, 보관 유지 보수 수수료, 고정 수수료가 적게 사용되는 이유가 포함됩니다.

임시 비용인 대역폭 및 컴퓨팅과 달리 스토리지는 이 두 비용과 달리 임시 한계를 초과합니다.

블록 시간 내에 노드가 수행하거나 데이터를 다운로드할 수 있는 계산 수에는 제한이 있으며 블록을 통과하면 다운로드 및 검증에 필요한 양에 도달합니다. 대부분의 블록이 사라졌습니다(향후 몇 개의 동기화 노드만 처리해야 함).

그리고 스토리지는 지속적인 비용입니다. 단일 블록 상태가 100MB 증가하면 해당 블록을 바로 처리할 수 있지만 일련의 블록은 이더리움을 사용할 수 없게 만듭니다. 상태 성장의 "폭발적인" 영향은 무시할 수 있지만 일단 매우 큰 상태가 설정되면 네트워크에 영구적으로 부담을 주기 때문에 장기적인 영향은 가장 심각합니다.

보조 제목

평균 크기 대 최악의 경우 스토리지 크기

현재(상태) 프로토콜(일반적으로 지속 불가능한 것으로 간주됨) 및 상태 만료가 있는 개선된 프로토콜에서 모델링 상태의 단점 중 하나는 평균 상태 성장과 최악의 상태 성장 간의 큰 차이입니다.

현재 프로토콜을 고려하십시오. 현재 상태의 총 크기는 약 5억 5천만 개체이며, 이는 약 32GB입니다(트라이 오버헤드 제외). 전년도의 손대지 않은 상태를 모두 제거하면 총계가 쉽게 절반 이상 떨어질 수 있습니다.

자, 최악의 상황은 무엇입니까?

컨트랙트 코드 생성은 바이트당 200Gas의 수수료가 부과되기 때문에 블록을 3개의 트랜잭션으로 나누어 각각의 트랜잭션이 컨트랙트를 생성한다면 12334800Gas+3*55000Gas에 대해 20558바이트의 3개 컨트랙트를 생성할 수 있습니다. 계약 생성의 오버 헤드.

이러한 방식으로 단일 블록에서 스토리지 크기를 20600*3=61800바이트만큼 늘릴 수 있습니다.

평균 블록 생성 시간을 13.1초라고 가정하면 연간 31556925/13.1=2408925개의 블록이 생성되며, 일반적으로 상태는 61800*2408925=148871600381.67938바이트, 약 138GB까지 증가할 수 있습니다.

이 차이는 약 10배입니다. (화이트 플랜 참고: 아래의 16GB 데이터는 맥락에 따라 1년 동안 현재 이더리움의 총 상태 크기로 이해됩니다.)

매우 중요한 것은 소비자 하드웨어 RAM이 16GB가 될 수 있는 실제 크기를 저장할 수 있고(그렇지 않은 경우 가스 가격이나 상태 만료를 조정하여 적합하도록 할 수 있음) 138GB는 저장할 수 없다는 것입니다.

보조 제목

듀얼 트랙 EIP-1559

이 문제에 대한 자연스러운 해결책은 임시 및 영구 비용에 대해 EIP-1559 가격을 사용하지만 조정 기간은 다릅니다.

임시 비용의 경우 한 번에 10% 이상 가격을 조정할 수 있습니다. 그러나 영구 비용의 경우 가격 조정이 훨씬 느려집니다.

AMM 비용 곡선 메커니즘을 기초로 삼는 경우 스토리지의 경우 목표 속도가 월 1GB인 곡선을 고려할 수 있으며 비용은 목표를 얼마나 초과하는지에 따라 증가합니다.

예를 들어 스토리지 비용은 목표를 초과하는 모든 GB에 대해 두 배가 될 수 있습니다. 이 경우 스토리지 블록 가격이 두 배가 되기까지 약 3일이 소요될 수 있습니다. 스토리지가 10GB를 초과하면 스토리지 비용이 정상 가격의 1000배가 되어 계속 저장하는 것이 경제적으로 불가능합니다.

이를 달성하는 방법에는 두 가지가 있습니다.

1. 가스로 저장 공간을 구매합니다. 즉, SSTORE를 사용하여 새 스토리지 슬롯을 생성하면 지금처럼 Gas를 소비하지만 소모되는 Gas의 양은 가변적입니다. 이것의 단점은 사용자가 가스 가격이 더 낮은 주말에 스토리지를 리필하도록 (위장된) 인센티브를 생성한다는 것입니다.

2. ETH로 스토리지를 구매합니다. Gas 외에도 트랜잭션(및 호출)은 Gas와 유사한 메커니즘을 사용하지만 매개 변수가 다른 또 다른 리소스(마나라고 부를 수 있음)를 제공해야 합니다. 이는 호출 규칙을 복잡하게 하고 새로운 CALL opcode를 추가해야 한다는 단점이 있습니다.

여기에 하이브리드 옵션이 있습니다.

3. 저장소는 ETH로 가격을 책정할 수 있지만 Gas로 청구됩니다(따라서 기본 요금이 두 배가 되면 저장소 슬롯을 채우는 데 필요한 Gas는 자동으로 절반이 됩니다). EIP 1559 가스 가격 업데이트 규칙 또는 블록 제한에서 스토리지 확장에 사용되는 ETH를 제외할 수 있습니다.

4. Gas를 Gas, Execution Point 및 Storage Point의 세 가지 개념으로 보다 포괄적으로 변환합니다. 1Gas=1wei; Gas를 할당하는 트랜잭션은 단순히 wei의 일부를 리소스 비용을 지불하는 데 사용할 수 있는 특수한 형태로 변환한다는 의미입니다. 이 형식은 호출과 하위 호출 간에 전달되는 방식 측면에서 Gas와 동일하게 작동합니다.

그러나 AMM은 이제 실행 지점 비용과 저장 지점 비용이라는 두 가지 비용을 관리합니다. 실행 프로세스가 현재 N gas를 소비하는 opcode를 처리할 때 N 실행 포인트를 소비하게 됩니다. 즉, Gas를 지불하려면 N* execution_point_cost가 필요합니다. 저장소 슬롯을 채우려면 저장소 1포인트가 필요하므로 Gas를 충전하려면 storage_point_cost가 필요합니다.

마지막으로, 환불은 주 기한 로드맵에서 제거될 것으로 예상됩니다. 이는 기술적인 이유 때문입니다. 저장소 슬롯은 "비워질 수" 없고 환불을 받을 수 없으므로 0으로만 설정할 수 있으며 기간이 종료되고 상태가 만료될 때까지 0개의 레코드가 해당 상태로 유지되어야 합니다. 이렇게 하면 이전 스토리지 임대 시도에서 발생한 복잡성 문제가 크게 줄어듭니다.

퍼블릭 체인

Odaily 공식 커뮤니티에 가입하세요

구독 그룹

https://t.me/Odaily_News

채팅 그룹

https://t.me/Odaily_CryptoPunk

공식 계정

https://twitter.com/OdailyChina

채팅 그룹

https://t.me/Odaily_CryptoPunk