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

NIC Lin, Medium

펙트라 하드포크는 2025년 3월 메인넷 배포를 시작할 예정이며, 펙트라 업그레이드에는 다음과 같은 11개의 기술 프로토콜(EIP)이 포함되어 있습니다.

• EIP-2537 : BLS12-381 커브 연산 사전 컴파일

• EIP-2935: 상태 내 과거 블록 해시 값 저장

• EIP-6110: 온체인 검증자 예치금 제공

• EIP-6110 p>

• EIP-7002: 실행 레이어 트리거 종료

• EIP-7251: MAX_EFFECTIVE_BALANCE 증가

• EIP-7549:  위원회 인덱스를 유효성 검사 밖으로 이동

• EIP-7623: 콜데이터 비용 증가

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

• EIP-7691. 블롭 처리량 증가

• EIP-7702: EOA 계정 코드 설정

• EIP-7840: EL 구성 파일에 블롭 계획 추가

EIP-6110: BLS12-381 커브 작업 사전 컴파일

서약에 대한 사용자 참여 처리를 간소화하여 대기 시간을 크게 단축할 수 있습니다.

사용자의 서약 참여는 실행 레이어에 32개의 이더를 저장하고 이벤트 로그에 기록하면 합의 레이어 실행이 이벤트 로그를 파싱하여 누군가가 서약에 참여했는지 확인하고, 서약에 참여한 사용자가 검증자가 되는 방식으로 이루어집니다.

그러나 합의 레이어 검증자는 먼저 어느 시점에 어떤 예치를 할 것인지 합의해야 합니다. 그렇지 않으면 어떤 검증자는 5개의 새로운 예치를 볼 수 있지만 다른 검증자는 3개만 볼 수 있으므로 합의 레이어 검증자는 모든 사람이 동일한 eth1data 블록을 볼 수 있도록 참조할 eth1data 블록에 투표하게 됩니다.

그러나 초기에는 체인 포크로 이어질 수 있는 실행 레이어의 중대한 오류를 피하기 위해 참조 실행 레이어 블록(eth1data)은 약 10시간 이상 지난 실행 레이어 블록이 되어 중대한 오류가 발생할 경우 합의 레이어 개발자들이 이에 대응하고 처리할 충분한 시간을 갖도록 하지만, 이로 인해 서약에 참여하는 가장 빠른 시간은 효력이 발생하기 10시간 이상 전이 될 수 있습니다. 효력을 발휘합니다.

의 CL 블록은 10900000 eth1data, 10시간 전에 나타난 실행 수준 블록 21683339의 블록 해시를 포함합니다.

EIP-6110이 구현된 이후에는 컨트랙트에 대한 사용자의 서약 정보가 직접 실행 레이어의 일부가 되고, 합의 레이어 블록 자체에 실행 레이어 블록(eth1data가 아닌)이 포함되므로 합의 레이어 검증자는 합의 레이어 메모리 블록의 2/3 이상을 받기만 하면 "참조된 실행 레이어 메모리 블록이 동일한지 확인"하는 문제를 더 이상 고려할 필요가 없습니다. 합의 레이어 블록이 검증자의 3분의 2 이상에 의해 확인되면 동일한 실행 레이어 블록이 존재한다는 합의가 이루어집니다. 결과적으로 실행 레이어 블록이 처리된 후 13분 이내에 사용자의 서약을 검증할 수 있으며, 합의 레이어 클라이언트는 서약 데이터를 처리하는 데 사용되는 복잡한 로직을 제거할 수 있습니다.

EIP-7002: 과거 블록 해시를 '상태'에 저장

검증자가 서약에서 탈퇴하거나 자금과 수익금을 인출하는 과정을 개선하고 검증자의 위험을 줄이는 데 사용할 수 있습니다.

서약에 참여하려면 검증자 키와 출금 자격 증명이라는 두 가지 키가 필요합니다.

검증자 키는 검증자의 작업 내용에 사용되며, 출금 자격 증명은 검증자가 서약에서 탈퇴할 때 입금과 수익금을 출금할 주소에 사용됩니다. 또한, 검증인 키는 현재 Pledge를 출금하는 데 필요합니다.

검증자 키를 분실하면 검증자 작업을 수행할 수 없고, 서약에서 출금할 수 없으며, 출금 자격 증명을 분실하면 예치금과 수익금을 모두 잃게 됩니다. 또한 일부 사용자는 Lido와 같은 타사 서약 서비스를 이용하며, 이러한 플랫폼을 사용할 때 사용자는 출금 자격 증명을 직접 보관해야 하지만, 검증자 키는 서비스 제공자가 보관하고 사용자를 대신하여 검증자 작업을 수행합니다.

사용자는 EIP-7002 기술 프로토콜을 구현한 다음, 출금 자격 증명으로 출금 컨트랙트(0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA에 배포된)를 호출하여 직접 출금 자격 증명을 사용하여 담보물을 종료하거나 보증금과 수익금을 수령(부분 출금 컨트랙트)할 수 있습니다. 부분 출금은 제3자 담보 서비스 이용과 관련된 위험을 줄여줍니다. 또한 사용자가 직접 서약하고 검증자 키를 분실한 경우 서약을 종료하는 데에도 사용할 수 있습니다.

• 요청은 validator_pubkey와 amount 매개변수로 시작됩니다. validator_pubkey는 검증자의 (공개) 키이며, amount는 청구할 금액입니다.

• 요청을 시작하는 출금 자격 증명은 validator_pubkey의 출금 자격 증명이어야 합니다.

• 출금 계약을 호출하여 요청을 시작하면 가스 수수료(ETH)가 부과됩니다.

• 사용자의 출금 자격 증명이 컨트랙트인 경우 사용자는 먼저 출금 컨트랙트로 이동하여 수동 갱신 수수료의 현재 금액을 확인한 다음 요청을 시작하고 수동 갱신 수수료를 첨부할 수 있지만, 출금 자격 증명이 EOA 계정인 경우 정확한 수동 갱신 수수료 금액을 확인할 수 있는 방법이 없습니다. 그러나 출금 자격 증명이 EOA 계정인 경우 정확한 셀 갱신 금액을 알 수 있는 방법이 없으며, 요청이 성공적으로 수행되는지 확인하기 위해 초과 셀 갱신 수수료(환불 불가)를 미리 시뮬레이션하여 지불할 수만 있습니다.

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

EIP-7251: 최대 유효 잔액 추가 

최고 금액을 크게 늘려서 검증인 수를 줄일 수 있으며, 최대 금액에 도달하지 못한 검증인은 서약의 수익금을 자동으로 받을 수 있는 기능입니다.

사용자를 검증자로 서약하려면 사용자는 더도 말고 덜도 말고 최대 유효 잔액인 ETH를 제공해야 합니다(현재 최대 유효 잔액은 32 ETH입니다). 사용자가 1024개의 이더를 담보로 제공하면 32번 담보하고, 32개의 검증자를 활성화하고, 32개의 검증자 노드를 실행할 수 있습니다. 합의 레이어의 상태 데이터가 훨씬 더 커질 뿐만 아니라, 수만 개의 검증자 서명이 매 슬롯마다(12초마다) P2P 네트워크 레이어에서 전달되고 집계되기 때문에 합의 레이어의 P2P 네트워크 레이어에 가해지는 부하가 훨씬 더 커집니다.

EIP-7251이 구현된 이후에는 하한(MIN_ACTIVATION_BALANCE)은 32 이더로 유지되지만 상한(MAX_EFFECTIVE_BALANCE)은 2048 이더로 대폭 상향되어 32에서 2048 사이에서 원하는 수의 이더를 서약하고 서약 수익을 얻을 수 있게 됩니다. 32개에서 2048개 사이의 이더리움을 원하는 수량만큼 서약할 수 있으며, 서약을 통해 수익을 얻을 수 있습니다. 더 이상 주기적으로 수익을 인출할 필요가 없으며, 32개 이더리움을 모은 후 다시 서약을 계속할 수 있습니다.

현재 기존 검증인은 특별히 자신의 서약을 철회한 다음 다시 추가하기 위해 병합할 필요가 없으며, 실행 파일 수준에서 새로운 "서약 병합 계약"(0x00431F263cE400f4455c2dCf564e53007Ca4bbBb에 배포)을 사용하여 검증인의 철회에 의해 계약을 시작할 수 있습니다. 컨트랙트를 호출하여 예치금 통합 요청을 시작하기 위한 크리덴셜입니다.

• 예금 병합 요청의 매개변수에는 source_pubkey와 target_pubkey가 포함되며, 두 키 모두 검증자의 검증자 키이며, 소스 검증자는 대상 검증자에 병합됩니다.

• 요청을 시작하는 출금 자격 증명은 소스 검증자의 출금 자격 증명이어야 합니다.

• 요청을 시작하기 위한 통합 예금 계약 호출에는 현재 요청 수에 따라 계산되는 수수료(ETH)가 동반됩니다. 수수료는 현재 요청 수에 따라 계산되며 요청이 많으면 수수료가 올라갑니다.

• 사용자의 출금 자격 증명이 계약인 경우 수동 갱신 요청을 시작하기 전에 통합 예금 계약에 전화하여 현재 수동 갱신 금액을 확인한 후 수동 갱신에 첨부할 수 있지만, 출금 자격 증명이 EOA 계좌인 경우 정확한 수동 갱신 금액을 확인할 수 있는 방법이 없습니다. 그러나 출금 자격 증명이 EOA 계정인 경우 수동 갱신 수수료의 정확한 금액을 알 수 있는 방법이 없으며, 요청이 성공적으로 수행되는지 확인하기 위해 초과된 수동 갱신 수수료(환불 불가)를 미리 시뮬레이션하여 지불할 수만 있습니다.

주: 출금 자격증명 형식이 BLS 공개 키 형식인 경우, EL 주소 형식으로 변경하려면 전환을 수행해야 합니다.

EIP-7685: 일반 실행 레이어 요청

사용자와 서약 서비스가 합의 레이어로 직접 요청을 보낼 수 있도록 공식 EL -> CL 메시지 파이프라인을 설정합니다.

사용자가 실행 레이어에서 합의 레이어로 직접 요청을 전송할 수 있게 함으로써, Lido와 같은 서약 서비스는 보다 탈중앙화된 방식으로 운영될 수 있습니다. 예를 들어, 앞서 언급한 EIP-7002를 통한 예치금 종료 요청과 EIP-7251을 통한 예치금 통합 요청이 있습니다. 이 프로토콜이 없었다면, 합의 수준에서 의도한 대로 담보 인출이나 예금 통합을 실행하기 위해 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 계정에서는 하나의 트랜잭션만 수행할 수 있습니다. 예를 들어, 유니스왑에서 USDT를 ETH로 교환하려면 먼저 USDT를 승인하는 트랜잭션을 시작한 다음 다른 트랜잭션을 전송하여 교환을 수행해야 합니다.

• 계정의 특정 작업을 제삼자에게 맡기는 등 권한을 제어할 수 있는 방법이 없기 때문에 사용자가 모든 작업을 직접 처리하고 모든 작업에 대해 한 번씩 서명해야 합니다.

• 복구 메커니즘이 없어 개인 키나 니모닉을 직접 보관해야 하며, 분실 시 계정의 자산을 되찾을 수 없습니다.

스마트 컨트랙트 계정(예: Safe)인 경우 위의 문제를 해결할 수 있습니다.

• 사용자는 개인키나 니모닉을 기억하지 않고 휴대폰(또는 컴퓨터)의 보안칩에 있는 개인키를 사용하여 승인에 서명할 수 있습니다. 또는 이메일 또는 기타 다양한 인증 방법으로 인증에 서명할 수 있습니다.

• 여러 작업을 함께 패치하여 단일 트랜잭션으로 수행할 수 있으므로, 기존에 복잡했던 디앱 작업을 한 번의 서명과 승인, 그리고 단일 트랜잭션으로 완료할 수 있습니다.

• 권한을 매우 세밀하게 제어할 수 있습니다. 사용자는 제3자가 자신의 계정을 제어하도록 승인하는 동시에 '어떤 컨트랙트와 상호작용할 수 있는지', '어떤 작업을 수행할 수 있는지', '자산 전송에 사용할 수 있는 최대 자산 수', '주당 수행할 수 있는 최대 작업 수' 등의 제한을 지정할 수 있습니다.

• 복구 메커니즘을 추가하면 니모닉이나 휴대폰, 이메일을 분실했을 때 자신의 계정에서 새 계정으로 자산을 옮길 수 있습니다.

EIP-7702 제안은 EOA 계정에 계약 계정으로 전환할 수 있는 권한을 부여하는 것입니다. 사용자는 "체인 ID", "변환된 컨트랙트 주소", "EOA의 논스 값"이 포함된 EOA 개인 키로 변환된 메시지에 서명합니다.

• 체인 ID: A-체인의 서명이 B-체인에서 재생되는 것을 방지하는 데 사용됩니다. 그러나 체인 ID가 0으로 채워지면 모든 체인에서 변환할 의향이 있음을 나타냅니다.

• 변경하려는 컨트랙트 주소: 세이프 컨트랙트 주소를 입력하면 EOA 계정이 세이프 컨트랙트로 변경되며, 널 주소(주소(0))를 입력하면 변경을 취소하고 일반 EOA 계정으로 돌아가고 싶다는 의미입니다.

• EOA의 논스 값: 서명이 재생되지 않도록 하는 데 사용됩니다. 논스 값이 증가하면 원래 서명이 무효화됩니다.

그러나 몇 가지 유의해야 할 사항이 있습니다.

1. EOA 개인키는 계속 사용할 수 있습니다

사용자의 EOA 계정이 컨트랙트로 전환되더라도 원래 EOA 계정과 동일한 방식으로 계속 사용할 수 있습니다. 예를 들어, EOA 계정이 세이프 컨트랙트로 전환된 경우 세이프 인터페이스를 사용하고 세이프 거래 절차를 거쳐 원래 EOA 지갑으로 계속 거래에 서명할 수 있습니다. 그러나 이는 계정의 보안이 여전히 개인 키로 제한된다는 것을 의미합니다.

2. 여전히 EOA 키 보안

사용자의 EOA가 다중 서명이 되더라도 EOA 키를 분실하지 않는 한 계정 보안은 항상 EOA 키 보안이며, 사용자는 여전히 키 또는 니모닉을 관리해야 하며 계정의 보안이 다중 서명만큼 안전해지지는 않습니다.

3. EOA 계정의 저장소가 포맷되지 않음

EOA 계정이 컨트랙트로 모핑되어 저장소에 데이터를 기록할 때, 데이터를 삭제하는 작업을 명시적으로 수행하지 않는 한 해당 데이터가 다른 컨트랙트로 모핑되거나 모핑이 취소되지 않으므로 개발자는 다음과 같은 점에 주의해야 합니다. 따라서 개발자는 ERC-7201에 설명된 대로 스토리지가 이전에 모핑된 컨트랙트가 남긴 데이터를 읽지 않도록 주의해야 합니다.

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

일반적으로 컨트랙트 틸은 초기화 단계가 필요하므로 틸을 배포하는 동안 공개 키 또는 주소와 같은 소유자에 대한 정보를 동기적으로 기록하여 틸이 손실되는 선제 배포 단계(Frontrun)를 방지해야 합니다. 프론트런) 배포 단계에서 계정 소유권을 잃을 수 있습니다. 이는 일반적으로 계약된 계정을 배포하는 팩토리 컨트랙트에 의해 수행되지만, EIP-7702는 팩토리가 계약을 EOA에 배포하는 것이 아니라 직접 변경하기 때문에 공격자가 사용자의 변환 서명을 복사하고 선제적으로 트랜잭션을 체인 위로 전송하여 사용자의 계정을 변환하지만 공격자가 제어할 수 있는 것으로 계정을 초기화할 수 있으므로 개발자는 이를 인지할 필요가 있습니다. 초기화 함수 내에서 EOA 계정의 서명을 확인하여 공격자가 선점하더라도 초기화를 완료할 수 있는 서명을 생성할 수 없도록 하는 등의 예방 조치를 취할 수 있습니다.

5. 지갑은 변경 요청을 게이트해야 합니다

악성 디앱 사이트에서 사용자에게 변경 트랜잭션에 서명하도록 요청할 때 지갑은 사용자를 위해 이 작업을 수행하여 사용자가 악의적인 변경 트랜잭션에 서명하면 자산이 즉시 전송되는 것을 차단하고 사용자에게 경고해야 합니다. 다음은 실제 작동하는 변형 계약의 몇 가지 예시입니다:

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

• 이타카 계정

<>< strong>DApp 기술 프로토콜

EIP-2537: BLS12-381 커브 조작 사전 컴파일

BLS 커브 기반 영지식 증명 애플리케이션을 더 저렴하고 저렴하게 만들 수 있습니다.

EIP-2537은 몇 가지 사전 컴파일 컨트랙트를 추가하여 저렴한 BLS 곡선 연산을 제공함으로써 영지식 증명을 위한 BLS 곡선 기반 애플리케이션을 더 쉽게 개발할 수 있도록 합니다.

EIP-2935: 과거 블록 해시를 스테이트에 저장

개발자나 노드가 시스템 컨트랙트의 스토리지에서 직접 과거 블록 해시를 읽을 수 있게 합니다.

가상의 옵티미스틱 롤업 사기 챌린지에서와 같이 개발자가 과거 1000개의 메모리 블록에 특정 트랜잭션이 존재한다는 것을 증명해야 하는 경우, 챌린저가 과거 메모리 블록의 내용을 증명할 수 있는 방법이 없습니다.

"이 트랜잭션이 1000개의 메모리 블록 전에 실제로 존재했다는 것을 믿어주세요"라고 증명해야 하지만, "1000개의 이전 메모리 블록에 이 내용이 포함되어 있다"는 직접적인 증거가 없기 때문에 1000개의 이전 메모리 블록에 도달할 때까지 메모리 블록을 "연쇄"하는 방식으로 메모리 블록별로 증명해야 하며, 이를 증명하기 위해서는 다음을 증명해야 합니다. 그 트랜잭션이 해당 메모리 블록에 존재한다는 것을 증명해야 합니다.

△ 각 블록은 부모 블록을 가리키므로 다음 블록까지 올라갈 수 있습니다. 부모 블록을 가리키므로 히스토리의 모든 블록을 거슬러 올라갈 수 있습니다.

현재 10000 블록에 있고, 9000 블록에 트랜잭션 X가 존재한다는 것을 증명하는 것이 사기 도전이라고 가정하면, 도전자는 10000 블록의 해시부터 시작하여 10000 블록이 연결된 부모 블록 9999의 해시를 증명한 다음 9998... 메모리 블록 9998까지 블록을 증명해야 합니다. 9998...메모리 블록 9000까지, 그리고 마지막으로 메모리 블록 9000의 내용에 트랜잭션 X가 포함되어 있음을 제안합니다.

EIP-2935 이후에는 시스템 계약(0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC에 배포됨)이 있습니다. 저장소는 이전 메모리 블록의 해시를 최대 8192개까지 저장합니다. 새 메모리 블록이 생성될 때마다 이 시스템 컨트랙트는 자동으로 업데이트되어 이전 블록의 해시를 시스템 컨트랙트에 기록합니다(이전 블록 8192개의 해시를 덮어씁니다).

이러한 방식으로 낙관적 롤업 사기 챌린지의 경우, 챌린저는 메모리 블록 하나하나를 증명할 필요 없이 메모리 블록 10000의 현재 체인 상태에서 시스템 컨트랙트의 스토어 중 하나(메모리 블록 9000에 해당)의 값이 메모리 블록 9000의 해시임을 증명하면 됩니다. 메모리 블록 1000과 같이 범위가 8192보다 큰 경우, 메모리 블록 1808(= 10000 - 8192)의 해시를 증명한 다음 메모리 블록 1808 아래의 체인 상태에서 시스템 컨트랙트의 메모리 블록 1000의 해시를 증명하는 것이 최대 한 단계 더 필요합니다.

이는 또한 미래의 라이트 노드가 모든 메모리 블록의 블록 헤더를 히스토리에 저장하는 대신 메모리 블록의 해시값이나 히스토리에 있는 메모리 블록의 내용을 사용하는 대신 이전 사기 챌린지 예시와 동일한 증명 방법을 사용하여 다른 노드에게 증명을 제공하도록 요청할 수 있는 길을 열어줍니다. 를 사용하여 이전 부정 챌린지 예제의 증명 방법을 사용하여 증명을 제공하도록 요청할 수 있습니다.

EIP-7623: : 콜데이터 비용 증가

블록 가스 한도와 블롭 수를 늘리기 위한 충분한 안전 공간을 확보하기 위해 콜데이터를 사용한 데이터 게시 비용을 증가시킵니다.

롤업의 데이터 배포 요구가 커지고, 롤업의 데이터 배포를 매우 저렴하게 하기 위해 EIP-4844에 블롭이 도입된 이후 블롭 수를 늘리는 것은 오랫동안 기다려온 업그레이드였으며, 최근 블록 가스 한도를 늘리려는 경우처럼 보다 강력한 방식으로 자원을 늘려야 할 필요성에 대한 대응이기도 합니다.

△블록 가스 한도를 늘리는 것에 대한 지지가 높아지고 있습니다.

블록 가스 한도나 블롭 수 증가 모두 거래되는 데이터의 양이 많아질수록 이더리움의 P2P 네트워크에 더 많은 부담을 주며, 데이터 배포 비용도 증가하지 않으면 공격자의 공격이 더 효율적으로 이루어질 수 있습니다.

EIP-7623 프로토콜이 출시되면 콜데이터 비용은 "제로 바이트: 4 가스, 비제로 바이트: 16 가스"에서 "제로 바이트: 10 가스, 비제로 바이트: 40 가스"로 2.5배 증가하게 됩니다.

원래 공격자가 스팸에 블록 가스 제한(30M)을 모두 사용할 경우 블록 크기는 약 1.79MB(30M/16)로 평균 블록 크기인 약 100KB와 비교하면, 블록 가스 제한이 40M로 상향되면 공격자는 약 2.38MB의 블록을 생성할 수 있게 됩니다. 블록 가스 제한을 40M으로 올리면 공격자는 약 2.38MB 크기의 메모리 블록을 생성할 수 있습니다. 콜데이터 비용이 2.5배 증가하면 공격자의 효율성은 30M의 경우 최대 0.72MB, 40M의 경우 0.95MB로 감소하므로 블록 가스 제한과 블롭의 수를 더 신중하게 늘릴 수 있습니다. 그러나 프로토콜은 "통화 데이터를 가져와 게시하지 않는" 일반 사용자에게 영향을 미치고 싶지 않기 때문에 트랜잭션의 총 가스 사용량을 두 가지 방법으로 계산한 다음 둘 중 더 높은 값을 사용합니다.

1. 거래의 가스 사용량을 계산하는 원래 방법, 이전과 함께 calldata 비용: 즉, 트랜잭션 실행에 소비된 Gas와 컨트랙트 배포에 소비된 Gas를 더하여 "0 바이트: 4 Gas, 비제로 바이트: 16 Gas"로 계산합니다.

2. 콜데이터 Gas 사용량 계산은 간단하지만 새로운 비용으로 계산합니다. 콜데이터는 "제로 바이트: 10 가스, 비제로 바이트: 40 가스"로 계산되지만 트랜잭션을 실행하는 데 소비되는 가스나 컨트랙트를 배포하는 데 소비되는 가스는 고려하지 않습니다. 따라서 "데이터를 게시하기 위해 콜데이터를 사용하지 않는" 일반 사용자(예: 유니스왑에 가서 교환하는 사람)의 경우 주요 가스 비용은 거래 비용이 될 수 있습니다. 따라서 "데이터를 게시"하지 않는 사용자(예: 데이터를 교환하기 위해 유니스왑에 방문하는 사용자)의 경우 주요 가스 소비량은 실행에 있으며, 콜데이터가 새로운 비용으로 계산되더라도 실행에 소비되는 가스량을 초과하지 않으므로 일반 사용자에게는 영향을 미치지 않습니다.

실제 영향은 소규모 롤업에 미칠 것입니다. Blob은 고정 크기, 고정 비용 솔루션이므로 소규모 롤업은 Blob을 사용하면 비효율적이고 콜데이터가 더 비용 효율적이지만 EIP-7623에서는 이러한 롤업의 비용이 2.5배 증가하므로 Blob으로 전환하거나 콜데이터로 전환해야 할 수 있습니다. 블롭 사용으로 전환하거나 블롭을 공유하기 위해 힘을 합치는 방법을 찾아야 할 수도 있습니다.

EIP-7691: 블롭 처리량 증가

블롭 수를 강조하면 롤업이 데이터를 게시할 수 있는 공간이 증가합니다.

블롭 수를 강조하면 롤업이 데이터를 게시할 수 있는 공간이 증가합니다.

EIP-7691은 데이터 게시에 사용 가능한 블롭 수를 늘립니다. EIP-7691은 블롭 수를 "대상: 3 블롭, 최대: 6 블롭"에서 "대상: 6 블롭, 최대: 9 블롭"으로 강조 표시하여 롤업이 데이터를 게시할 수 있는 공간을 더 늘렸습니다.

주: 블롭 수동 갱신 시장의 일부 설계 측면도 미세 조정이 필요한데, 핸드 갱신 조정 속도가 충분히 즉각적이지 않거나 핸드 갱신 바닥이 너무 낮다는 등의 문제가 있지만 이는 블롭 수동 갱신 시장 설계의 일부가 아닙니다. 너무 낮다는 지적이 있지만 이는 이 기술 계약이 다루는 문제가 아닙니다.

기타 프로토콜

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

인증자의 투표 내용을 조정하여 투표를 쉽게 집계하고 P2P 네트워크의 힘을 줄일 수 있도록 합니다.

인증자는 에포크당 위원회 그룹에 무작위로 할당되어 메모리 블록에 투표하며, 각 위원회에 대한 인증자의 투표를 합산하여 P2P 네트워크를 통과하는 투표 수를 줄일 수 있지만 인증자의 투표에는 "이 인증자가 속한 위원회"라는 정보가 포함되므로 위원회마다 다른 투표 수를 가지게 됩니다.

그러므로 서로 다른 위원회의 투표가 모두 동일한 메모리 블록에 투표하더라도 합산되지 않습니다.

EIP-7549는 투표 내용에서 "이 검증인이 속한 위원회" 정보를 제거하여 투표 내용이 동일한 경우 다른 위원회의 검증인이 함께 집계될 수 있도록 하여 P2P 네트워크를 통과하는 투표의 수를 더욱 줄이고 P2P 네트워크의 힘을 줄입니다.

EIP-7840: EL 구성 파일에 블롭 체계 추가

실행 레이어에서 블롭 매개변수에 대한 프로파일을 생성하면 실행 레이어 노드가 합의 레이어 노드에 블롭 관련 매개변수를 요청할 필요가 없습니다.

블롭 파라미터는 현재 합의 노드에 저장되어 있지만, 실행 레이어 노드는 특정 상황(예: RPC eth_feeHistory)에서 이를 필요로 하므로 합의 노드에 요청해야 합니다.

EIP-7840은 실행 레이어에서 블롭 파라미터의 프로파일을 생성하고, 실행 레이어 노드는 합의 레이어 노드에 요청하지 않고 이 프로파일에서 직접 블롭 파라미터를 읽을 수 있습니다.