이더리움 펙트라 하드 포크 소개

Pectra 하드 포크는 2025년 3월에 메인넷 배포를 시작할 예정입니다. Pectra 업그레이드에는 11개의 기술 프로토콜(EIP)이 포함됩니다.

원문: Ethereum Pectra Hard Fork 소개

저자: NIC Lin

편집자: imToken

표지: Unsplash 의 Shubham Dhage가 찍은 사진

Pectra 하드 포크는 2025년 3월에 메인넷 배포를 시작할 예정입니다. Pectra 업그레이드에는 다음과 같은 11개의 기술 프로토콜(EIP)이 포함됩니다.

• EIP-2537: BLS12-381 곡선 연산 사전 컴파일
• EIP-2935: State에 기록 블록 해시 저장
• EIP-6110: 온체인 검증자 입금 제공
• EIP-7002: 실행 계층이 종료를 트리거함
• EIP-7251: MAX_EFFECTIVE_BALANCE 증가
• EIP-7549: 검증 외부에서 위원회 인덱스 이동
• EIP-7623: 통화 데이터 비용 증가
• EIP-7685: 일반 실행 계층 요청
• EIP-7691: Blob 처리량 증가
• EIP-7702: EOA 계정 코드 설정
• EIP-7840: EL 구성 파일에 Blob 계획 추가

약속과 관련된 기술 계약

EIP-6110: BLS12-381 곡선 연산 사전 컴파일

사용자가 스테이킹에 참여하는 프로세스를 간소화하고 대기 시간을 크게 단축합니다.

사용자가 스테이킹에 참여하는 방법은 실행 계층에 32 ETH를 입금하고 이벤트 로그에 기록하는 것입니다. 그런 다음 합의 계층은 이벤트 로그를 실행하고 구문 분석하여 스테이킹에 참여한 사람이 있는지 확인한 다음 스테이킹에 참여한 사용자가 검증자가 됩니다.

그러나 합의 계층의 검증자는 먼저 입금이 이루어진 시점에 대한 합의에 도달해야 합니다. 그렇지 않으면 일부 검증자는 5개의 새로운 입금을 보고, 일부 검증자는 3개만 볼 것입니다. 따라서 합의 계층 검증자는 모든 사람이 동일한 실행 계층 블록을 볼 수 있도록 하기 위해 참조할 실행 계층 블록(eth1data)에 대해 투표합니다.

그러나 체인 포크로 이어질 수 있는 실행 계층의 주요 오류를 피하기 위해 참조 실행 계층 블록(eth1data)은 약 10시간 전의 실행 계층 블록이었으며, 주요 오류가 발생할 때 합의 계층 개발자가 대응할 충분한 시간을 확보할 수 있도록 했습니다. 그러나 이는 스테이킹 참여가 적용되려면 최소 10시간이 걸린다는 것을 의미합니다.

EIP-6110 기술 프로토콜을 실행한 후, 계약에 대한 사용자의 약속 정보는 실행 계층의 일부가 됩니다. 합의 계층 블록 자체에 실행 계층 블록(eth1data는 아님)이 포함되기 때문에 합의 계층 검증자는 더 이상 "참조 실행 계층 메모리 블록이 동일한지 확인하는" 문제를 고려할 필요가 없습니다. 합의 계층 메모리 블록이 검증자의 3분의 2 이상에 의해 투표되고 확인되는 한, 모든 사람이 동일한 실행 계층 블록을 보고 있다는 합의에 도달하게 됩니다. 따라서 사용자가 스테이킹에 참여한 후 실행 계층 메모리 블록이 처리된 후 단 13분 만에 플레지가 적용되고, 합의 계층 클라이언트도 원래 스테이킹 데이터를 처리하는 데 사용된 복잡한 로직을 제거할 수 있습니다.

EIP-7002: State에 기록된 블록 해시 저장

이는 검증자가 스테이킹을 종료하거나 예치금과 수익을 인출하는 프로세스를 개선하고, 검증자의 위험을 줄이는 데 사용될 수 있습니다.
스테이킹에 참여하려면 검증자 키와 출금 자격 증명이라는 두 가지 키가 필요합니다.
Validator Key는 검증자의 작업 내용에 사용되고, Withdrawal Credential은 검증자가 스테이킹을 종료할 때 입금 및 수입이 클레임 될 주소에 사용됩니다. 또한, Validator Key 작업은 현재 스테이킹을 종료하는 데 필요합니다.
검증자 키를 분실하면 검증자 작업을 수행할 수 없고 스테이킹에서 출금할 수 없습니다. 출금 자격 증명을 분실하면 모든 입금 및 수익을 잃게 됩니다. 또한 일부 사용자는 Lido와 같은 타사 스테이킹 서비스를 사용합니다. 이러한 플랫폼을 사용할 때 사용자는 인출 자격 증명을 스스로 보관해야 하지만 검증자 키는 서비스 제공자가 보관하고 대신 검증자의 작업을 수행합니다.
EIP-7002 기술 프로토콜을 실행하면 사용자는 인출 자격 증명을 사용하여 "인출 계약"(0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA에 배포)을 호출해 스테이킹을 종료(종료)하거나 입금 및 수익을 인출(부분 인출)할 수 있으며, 이를 통해 타사 스테이킹 서비스 사용과 관련된 위험을 줄일 수 있습니다. 사용자가 스스로 스테이킹에 참여하였으나 검증자 키를 분실한 경우, 이를 사용하여 스테이킹에서 인출할 수도 있습니다.

• 요청을 시작하기 위한 매개변수에는 validator_pubkey와 amount가 포함됩니다. validator_pubkey는 검증자의 검증자(공개) 키이고, amount는 인출할 금액입니다.
• 요청을 시작하는 데 사용되는 인출 자격 증명은 validator_pubkey 검증자의 인출 자격 증명이어야 합니다.
• 인출 계약을 호출하여 요청을 시작할 때 가스 수수료(ETH)를 첨부해야 합니다. 가스 수수료는 현재 인출 요청 수에 따라 계산됩니다. 요청 수가 많으면 가스 수수료가 상승.
• 사용자의 출금 자격 증명이 계약인 경우, 먼저 출금 계약으로 가서 현재 수수료 금액을 알아낸 다음, 요청을 개시하고 수수료를 첨부할 수 있습니다. 하지만 출금 자격 증명이 EOA 계정인 경우, 정확한 수수료를 알아낼 방법이 없고, 사전에 오프체인에서 수수료를 시뮬레이션하고 초과 수수료(환불되지 않음)를 지불하여 요청이 성공적으로 실행되도록 할 수 있습니다.

참고: 출금 자격 증명이 여전히 BLS 공개 키 형식을 유지하는 경우 먼저 EL 주소 형식으로 전환해야 합니다.

EIP-7251: MAX_EFFECTIVE_BALANCE 증가

스테이킹 금액의 상한선을 대폭 늘려 검증자 수를 줄일 수 있으며, 상한선에 도달하지 않은 검증자는 자동으로 스테이킹 수익을 누릴 수 있습니다.

검증자가 되려면 사용자는 MAX_EFFECTIVE_BALANCE 이상의 ETH를 제공해야 하며, 이보다 적거나 많아도 안 됩니다(현재 MAX_EFFECTIVE_BALANCE는 32 ETH입니다). 사용자가 1024 ETH를 지분으로 보유하면 32회 지분에 참여하여 32개의 검증자를 활성화하고 32개의 검증자 노드를 운영할 수 있습니다. 모든 사람이 스테이킹에 적극적으로 참여함에 따라 현재 검증자 수는 약 100만 명이 되었고 계속 증가하고 있습니다. 합의 계층의 상태 데이터를 더 크고 더 많이 만드는 것 외에도 합의 계층 p2p 네트워크 계층의 부하가 더 큽니다. 각 슬롯(12초마다)에는 p2p 네트워크 계층에서 지속적으로 전송되고 집계되어야 하는 수만 개의 검증자 서명이 있기 때문입니다.
EIP-7251 기술 프로토콜을 실행한 후, 스테이킹 하한(MIN_ACTIVATION_BALANCE)은 여전히 ​​32 ETH이지만, 상한(MAX_EFFECTIVE_BALANCE)은 2048 ETH로 상당히 증가할 것입니다. 32에서 2048 사이의 ETH를 스테이킹할 수 있으며, 스테이킹 수입을 얻을 수 있습니다. 더 이상 수입을 정기적으로 인출할 필요가 없습니다. 32 ETH를 축적한 후 새로운 ETH를 계속 스테이킹할 수 있습니다.
현재 기존 검증자는 지분을 인출한 다음 다시 병합하여 지분을 인출할 필요가 없습니다. 대신 실행 계층에서 새로 추가된 "입금 병합 계약"(0x00431F263cE400f4455c2dCf564e53007Ca4bbBb에 배포됨)을 직접 사용하고 검증자의 인출 자격 증명을 사용하여 계약을 호출하여 입금 병합 요청을 시작할 수 있습니다.

• 병합 입금 요청의 매개변수에는 source_pubkey와 target_pubkey가 포함됩니다. 이 두 키는 검증자의 검증자 키이고, 소스 검증자는 대상 검증자에 병합됩니다.
• 요청을 시작하는 데 사용되는 인출 자격 증명은 소스 검증자의 인출 자격 증명이어야 합니다.
• 병합된 입금 계약을 호출하여 요청을 시작할 때 처리 수수료(ETH)를 첨부해야 합니다. 처리 수수료는 현재 요청 수에 따라 계산됩니다. 요청 수가 많으면 처리 수수료가 상승.
• 사용자의 출금 자격 증명이 계약인 경우, 결합된 입금 계약을 먼저 호출하여 현재 수수료 금액을 얻은 다음 요청을 시작하고 수수료를 첨부할 수 있습니다. 그러나 출금 자격 증명이 EOA 계정인 경우 정확한 수수료를 얻을 방법이 없습니다. 사전에 오프체인으로 시뮬레이션하고 초과 수수료(환불되지 않음)를 지불하여 요청이 성공적으로 실행되도록 할 수 있습니다.

참고: 출금 자격 증명이 BLS 공개 키 형식인 경우 먼저 EL 주소 형식으로 전환해야 합니다.

EIP-7685: 일반 실행 계층 요청

사용자와 스테이킹 서비스가 합의 계층에 직접 요청을 보낼 수 있도록 공식적인 EL -> CL 정보 파이프라인을 구축합니다.

사용자는 실행 계층에서 합의 계층으로 직접 요청을 보낼 수 있으며, 이를 통해 스테이킹 서비스(예: Lido)가 보다 탈중앙화 방식으로 작동할 수 있습니다. 예를 들어, 앞서 언급된 EIP-7002 스테이킹 종료 요청과 EIP-7251 입금 병합 요청이 있습니다. 이러한 기술 프로토콜이 없다면, Lido 사용자는 Lido 노드 서비스 제공자가 합의 계층에서 담보 종료나 예치금 병합을 충실히 실행할 것이라고 믿어야 합니다. 하지만 이 기술 프로토콜을 사용하면 Lido 사용자는 실행 계층의 거버넌스 계약을 통해 직접 요청을 보낼 수 있습니다.

이러한 요청은 다양한 유형의 요청을 구별하고 다양한 계약을 통해 요청을 시작하기 위해 요청 유형을 갖게 됩니다. 마지막으로 이러한 요청은 실행 계층 메모리 블록에 기록되므로 합의 계층은 개별 구문 분석 논리를 작성하지 않고도 실행 계층 메모리 블록을 통해 이 정보를 직접 얻을 수 있습니다.

EIP-6110, EIP-7002 및 EIP-7251은 모두 EIP-7685에서 정의한 표준을 기반으로 요청을 공식화합니다.

• EIP-6110은 스테이킹 요청을 추가합니다: 요청 유형=0, 입금 계약(0x00000000219ab540356cbb839cbe05303d7705fa)을 통해 요청을 시작합니다.
• EIP-7002 스테이킹 출금 요청: 요청 유형=1, 출금 계약(0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA)을 통해 요청을 시작합니다.
• EIP-7251 병합 입금 요청: 요청 유형=2, 통합 계약을 통해 요청을 시작합니다(0x00431F263cE400f4455c2dCf564e53007Ca4bbBb).

사용자 경험 향상을 위한 기술 협정

EIP-7702: EOA 계정 코드 설정

EOA 계정을 원하는 대로 계약 계정으로 전환할 수 있어 사용자 경험이 크게 향상되었습니다.

EOA 계정을 사용하는 데에는 다음과 같은 몇 가지 단점이 있습니다.

• 개인 키나 니모닉 문구를 기록하고 보관해야 하며, 신규 사용자가 등록하고 사용하는 데에는 기준이 높습니다.
• EOA 계정은 거래당 하나의 작업만 수행할 수 있습니다. 예를 들어, Uniswap에서 USDT를 ETH로 교환하려면 먼저 USDT를 승인하기 위한 거래를 시작한 다음, 다른 거래를 보내 교환을 수행해야 합니다.
• 계정의 특정 작업을 제3자에게 넘기는 것과 같이 권한을 세부적으로 제어하는 ​​것은 불가능합니다. 사용자는 모든 집안일을 직접 처리하고 각 작업에 대한 거래에 서명하고 보내야 합니다.
• 복구 메커니즘이 없으므로 개인 키나 니모닉 문구는 본인만 보관할 수 있습니다. 분실하면 자산을 돌려받을 수 없습니다.

스마트 계약 계정(Safe 등)인 경우 위의 문제는 다음과 같이 해결될 수 있습니다.

• 사용자는 개인 키나 기억술어를 기억할 필요 없이 휴대폰(또는 컴퓨터)의 보안 칩에 있는 개인 키를 사용하여 서명하고 승인할 수 있으며, 이메일을 통해 서명하고 승인하거나, 기타 다양한 승인 방법을 사용할 수 있습니다.
• 여러 작업을 함께 배치하여 동일한 트랜잭션에서 함께 실행할 수 있습니다. 이전에 복잡했던 DApp 작업은 단 하나의 서명 인증과 하나의 트랜잭션으로 완료할 수 있습니다.
• 매우 세부적인 권한 제어가 가능하며, 사용자는 제3자에게 자신의 계정을 제어하도록 권한을 부여하면서도 "상호 작용할 수 있는 계약", "수행할 수 없는 작업", "자산 이전에 사용할 수 있는 자산 양" 또는 "주당 수행할 수 있는 작업 수"와 같은 제한을 지정할 수 있습니다.
• 복구 메커니즘을 추가하면 니모닉 문구, 휴대전화 번호, 이메일을 분실한 경우 복구 메커니즘을 통해 계정 자산을 새 계정으로 이전할 수 있습니다.

EIP-7702 제안은 EOA 계정에 계약 계정으로 전환할 수 있는 기능을 제공하는 것입니다. 사용자는 EOA 개인 키로 변환된 메시지에 서명합니다. 서명 내용에는 "Chain ID", "변환된 계약 주소" 및 "EOA Nonce 값"이 포함됩니다.

• 체인 ID: 체인 A의 서명이 재생을 위해 체인 B로 옮겨지는 것을 방지하는 데 사용됩니다. 하지만 체인 ID가 0으로 채워지면 모든 체인에서 변환을 시도한다는 의미입니다.
• 변경하고자 하는 계약 주소: 안전 계약 주소를 입력하면 EOA 계정이 안전 계약으로 전환되고, 빈 주소(주소(0))를 입력하면 변경을 취소하고 단순 EOA 계정으로 다시 변경하고 싶다는 의미입니다.
• EOA의 Nonce 값: 서명이 재생되는 것을 방지하는 데 사용됩니다. Nonce 값이 증가하면 원래 서명은 유효하지 않게 됩니다.

다만 주의해야 할 점이 몇 가지 있습니다.

1. EOA 개인키는 계속 사용 가능합니다.

사용자의 EOA 계정이 계약으로 전환되더라도 원래 EOA 계정과 동일한 방식으로 계속 사용할 수 있습니다. 예를 들어, EOA 계정이 안전 계약이 되면 안전 인터페이스를 사용하여 안전 거래 프로세스를 따를 수도 있고, 원래 EOA 지갑을 사용하여 계속 거래에 서명하고 보낼 수도 있습니다. 하지만 이는 계정의 보안이 여전히 개인 키에 국한된다는 것을 의미합니다.

2. 여전히 EOA 개인 키의 보안성

사용자의 EOA가 다중 서명이 되더라도 EOA 개인 키를 잃어버리지 않는 한, 그의 계정의 보안은 항상 EOA 개인 키의 보안과 같을 것입니다. 여전히 그는 자신의 개인 키나 니모닉 문구를 잘 보관해야 하며, 그의 계정은 다중 서명만큼 안전하지 않을 것입니다.

3. EOA 계정의 저장공간은 포맷되지 않습니다.

EOA 계정이 계약으로 변환되고 해당 스토리지에 데이터를 쓸 때, 데이터가 명시적으로 삭제되지 않는 한, EOA 계정이 다른 계약으로 변환되거나 변환이 취소되기 때문에 스토리지에 쓰여진 데이터는 포맷되지 않습니다. 따라서 개발자는 이전 변환 계약에서 남은 데이터를 읽지 않도록 스토리지에 주의해야 합니다. ERC-7201을 참조하세요.

4. EIP-7702 프로세스에는 초기화가 포함되지 않습니다.

일반적으로 계약 계정은 계정이 배포될 때 계정 소유자의 정보(공개 키 또는 주소 등)를 동기적으로 작성하기 위한 초기화 단계가 필요합니다. 이는 배포 단계가 선행 실행되어 계정 소유권이 상실되는 것을 방지하기 위함입니다. 이는 일반적으로 "배포 + 초기화"를 수행하기 위해 계약 계정을 배포하는 팩토리 계약에 의해 수행되지만, EIP-7702는 팩토리가 EOA에 계약을 배포하는 것이 아니라 직접적인 변경이기 때문에 공격자는 사용자의 변환 서명을 복사하고 먼저 체인에 거래를 보내 사용자를 변환한 후 공격자가 제어할 수 있도록 계정을 초기화할 수 있으므로 개발자는 EIP-7702에 주의를 기울여야 합니다. 가능한 예방 방법으로는 초기화 함수에서 EOA 계정의 서명을 확인하는 것이 있습니다. 이렇게 하면 공격자가 선점당하더라도 EOA 계정의 서명을 생성하여 초기화를 완료할 수 없습니다.

5. 지갑은 변경 요청을 확인해야 합니다.

지갑은 사용자를 잘 선별해야 합니다. 악의적인 DApp 웹사이트가 사용자에게 변환된 거래에 서명하도록 요청하면 요청을 차단하고 사용자에게 경고해야 합니다. 그렇지 않으면 사용자가 악의적인 변환된 거래에 서명하면 자산이 즉시 이전됩니다. 변환 계약을 구현하는 방법에 대한 몇 가지 예는 다음과 같습니다.

• 수정된 안전 이타카 계정
• 이타카 계정

DApp 기술 프로토콜

EIP-2537: BLS12-381 곡선 연산 사전 컴파일

이를 통해 BLS 곡선을 기반으로 하는 제로 지식 증명 애플리케이션의 비용이 줄어들고 실행 가능성이 높아집니다.

EIP-2537은 저렴한 BLS 곡선 연산을 제공하기 위해 여러 개의 사전 컴파일된 계약(Precompile)을 추가하여 BLS 곡선을 기반으로 하는 제로 지식 증명 애플리케이션을 개발하는 것을 더욱 실현 가능하게 만듭니다.

EIP-2935: State에 기록 블록 해시 저장

개발자나 노드가 시스템 계약의 저장소에서 직접 과거 메모리 블록의 해시 값(블록 해시)을 읽을 수 있도록 허용합니다.

개발자가 이전 메모리 블록의 내용을 증명해야 하는 경우(예: Optimistic Rollup 사기 도전) 특정 거래가 1,000개의 이전 메모리 블록에 존재했다는 것을 증명해야 합니다. 도전자는 직접 말할 수 없습니다.

"이 거래가 실제로 1000개의 메모리 블록 전에 존재했다는 것을 믿어주세요." 그는 증거를 제시해야 하지만 "1000년 전의 메모리 블록에 이 내용이 들어 있다"는 것을 직접적으로 증명할 직접적인 증거는 없습니다. 따라서 그는 메모리 블록 "체인" 방법을 사용하여 1000년 전의 메모리 블록에 도달할 때까지 한 번에 한 개의 메모리 블록씩 증명한 다음, 그 거래가 해당 메모리 블록에 존재한다는 것을 증명해야 합니다.

현재 메모리 블록이 10000번이라고 가정하고, 사기 도전에는 특정 거래 X가 9000번 메모리 블록에 존재한다는 증명이 필요합니다. 도전자는 메모리 블록 10000의 해시 값에서 시작하여 먼저 메모리 블록 10000이 연결된 부모 메모리 블록 9999의 해시 값을 증명해야 하고, 그런 다음 메모리 블록 9998을 증명하고... 메모리 블록 9000까지 증명한 다음, 마지막으로 메모리 블록 9000의 내용에 거래 X가 포함되어 있다고 제안해야 합니다.

EIP-2935 이후에는 시스템 계약(배포)이 있을 것입니다.

0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC), 해당 저장소는 최대 8192개의 이전 메모리 블록의 해시 값을 저장합니다. 새로운 메모리 블록이 생성될 때마다 시스템 계약은 자동으로 업데이트되어 이전 메모리 블록의 해시 값을 시스템 계약에 씁니다(8192개 이전 메모리 블록의 해시 값이 덮어쓰여집니다).

이런 방식으로, 낙관적 롤업 사기 이의 제기의 예에서 이의 제기자는 한 번에 한 메모리 블록씩 증명할 필요가 없지만, 메모리 블록 10000의 체인의 현재 상태에서 시스템 계약의 스토리지(메모리 블록 9000에 해당)의 값이 메모리 블록 9000의 해시 값이라는 것을 직접 증명할 수 있습니다. 범위가 8192를 초과하는 경우(예: 메모리 블록 1000) 최대 한 단계가 더 있는데, 먼저 메모리 블록 1808의 해시 값(= 10000 - 8192)을 증명하고, 그 다음 시스템 계약에서 메모리 블록 1808의 현재 체인 상태에서 메모리 블록 1000의 해시 값을 증명합니다.

이는 또한 미래의 무상태 클라이언트를 위한 길을 열어줍니다. 미래의 라이트 노드는 더 이상 모든 블록 헤더를 기록에 저장할 필요가 없습니다. 대신, 기록에 있는 특정 메모리 블록의 해시 값이나 내용이 필요할 때, 이전 사기 도전 사례에서 증명 방법을 사용하여 다른 사람들에게 증명을 제공하도록 요청할 수 있습니다.

EIP-7623: 통화 데이터 비용 증가

블록 가스 한도와 Blob 수를 늘리기 위한 충분한 안전 여유를 확보하기 위해 calldata를 사용하여 데이터 게시 비용을 늘립니다.

Rollup 데이터 릴리스에 대한 수요가 증가함에 따라, Blob이 EIP-4844에서 도입되어 Rollup이 매우 저렴한 방식으로 데이터를 릴리스할 수 있게 된 후, Blob의 수를 늘리는 것은 커뮤니티 항상 기대해 온 업그레이드였습니다. 또는 최근 커뮤니티 Block Gas Limit을 늘리려는 것처럼, 이는 생태계가 리소스를 늘려야 한다는 요구를 반영합니다.

하지만 블록 가스 한도나 블롭의 수가 늘어나면 거래 데이터 양이 늘어나 공격자의 공격 효율성이 높아지기 때문에 이더리움의 P2P 네트워크에 더 많은 압박이 가해질 것입니다. 다만, 데이터 게시 비용도 늘어나지 않는 이상은 말입니다.

EIP-7623 프로토콜이 발표된 이후, 콜데이터 비용은 원래 "0바이트: 4가스, 0이 아닌 바이트: 16가스"에서 "0바이트: 10가스, 0이 아닌 바이트: 40가스"로 2.5배 증가하게 됩니다.

원래 공격자가 Block Gas Limit(30M) 전체를 사용하여 가비지 데이터를 저장하면 메모리 블록의 데이터 크기는 약 1.79MB(30M/16)가 되는데, 이는 평균 메모리 블록 크기가 약 100KB에 불과한 것과 비교됩니다. 또한 Block Gas Limit을 40M으로 높이면 공격자는 약 2.38MB의 메모리 블록을 생성할 수 있습니다. calldata 비용이 2.5배 증가하면 공격자의 효율성은 30M의 경우 최대 0.72MB, 40M의 경우 최대 0.95MB로 감소합니다. 이런 식으로 Block Gas Limit과 Blob 번호를 더 큰 확신을 가지고 늘릴 수 있습니다. 하지만 이 기술 프로토콜은 "데이터를 게시하기 위해 콜데이터를 사용하지 않는" 일반 사용자에게 영향을 미치고 싶지 않기 때문에 두 가지 방법으로 거래의 총 가스 사용량을 계산하여 더 높은 쪽을 선택합니다.

1. 원래의 트랜잭션 가스 사용량 계산 방법은 이전의 콜데이터 비용과 결합됩니다. 즉, 콜데이터는 "0바이트: 4가스, 0이 아닌 바이트: 16가스"로 계산되고, 트랜잭션 실행에 의해 소비된 가스와 계약 배포에 의해 소비된 가스가 추가됩니다.
2. 간단히 calldata 가스 사용량을 계산하지만, 새로운 비용을 사용합니다. 즉, calldata를 "제로 바이트: 10 가스, 0이 아닌 바이트: 40 가스"로 계산하지만 실행에 의해 소비된 가스나 계약을 배포하는 데 소비된 가스는 포함하지 않습니다. 따라서 "calldata를 사용하여 데이터를 게시하지 않는"(예: Uniswap에서 거래하는) 사용자의 경우 주요 가스 소비는 실행 부분에 있습니다. calldata가 새로운 비용으로 계산되더라도 실행에 의해 소비된 가스를 초과하지 않으므로 일반 사용자는 영향을 받지 않습니다.

실제로 영향을 받는 것은 소규모 Rollup입니다. Blob은 고정된 크기와 고정된 비용을 가지고 있기 때문에 소규모 Rollup이 Blob을 사용하는 것은 비효율적이고 calldata를 사용하는 것이 더 비용 효율적입니다. 그러나 EIP-7623 이후 이러한 소규모 Rollup의 비용은 2.5배 증가하므로 Blob을 사용하도록 전환하거나 Blob을 공유하기 위해 함께 결합하는 방법을 찾아야 할 수 있습니다.

EIP-7691: Blob 처리량 증가

Rollup에 데이터를 게시하기 위한 공간을 늘리려면 Blob의 수를 늘립니다.

EIP-7691은 "대상: 3개 블롭, 상한: 6개 블롭"에서 "대상: 6개 블롭, 상한: 9개 블롭"으로 블롭 수를 늘려 Rollup에 데이터를 게시하기 위한 공간을 늘립니다.

참고: 이 외에도 Blob 수수료 시장에는 미세 조정이 필요한 몇 가지 설계가 있습니다. 예를 들어 수수료 조정 속도가 즉각적이지 않거나 수수료 하한이 너무 낮습니다. 그러나 이는 이 기술 프로토콜이 해결하려는 문제가 아닙니다.

기타 기술 계약

EIP-7549: 검증 외부로 위원회 인덱스 이동

P2P 네트워크의 부담을 줄이고 투표 집계를 보다 쉽게 ​​하기 위해 검증자 투표의 내용을 조정합니다.

검증자는 각 Epoch에서 위원회 그룹에 무작위로 할당됩니다.

메모리 블록 투표의 경우, 각 위원회의 검증자의 투표를 함께 집계할 수 있으며, 이를 통해 p2p 네트워크에서 전송되는 투표 수를 줄일 수 있습니다. 그러나 검증자의 투표용지에는 "검증자가 속한 위원회"에 대한 정보가 포함되므로, 모두 같은 메모리 블록에 투표하더라도 다른 위원회의 투표를 함께 집계할 수 없습니다.

EIP-7549는 투표 내용에서 "검증자가 어느 위원회에 속해 있는가"에 대한 정보를 제거하여 투표 내용이 동일한 경우 다른 위원회의 검증자를 함께 집계할 수 있으며, 이를 통해 P2P 네트워크에서 전송되는 투표 수를 더욱 줄이고 P2P 네트워크의 부담을 줄일 수 있습니다.

EIP-7840: EL 구성 파일에 Blob 계획 추가

실행 계층에서 Blob 매개변수에 대한 구성 파일을 생성하면 실행 계층 노드가 합의 계층 노드에 Blob 관련 매개변수를 요청하는 번거로움을 줄일 수 있습니다.

Blob 관련 매개변수는 현재 합의 계층 노드에 저장되어 있지만 실행 계층 노드는 어떤 경우에는 여전히 이러한 매개변수가 필요합니다(예: RPC eth_feeHistory). 따라서 합의 계층 노드에 요청해야 합니다.

EIP-7840은 실행 계층에서 Blob 관련 매개변수에 대한 구성 파일을 만듭니다. 실행 계층 노드는 합의 계층 노드에 묻지 않고도 이 구성 파일을 통해 Blob 관련 매개변수를 직접 읽을 수 있습니다.

면책 조항: 블록체인 정보 플랫폼으로서, 이 사이트에 게시된 기사는 작성자와 게스트의 개인적인 견해만을 나타내며 Web3Caff의 입장과 아무런 관련이 없습니다. 기사의 정보는 참고용일 뿐이며 어떠한 투자 조언이나 제안도 구성하지 않습니다. 귀하의 국가 또는 지역의 관련 법률 및 규정을 준수하십시오.