프레임 트랜잭션과 개인정보 보호를 위한 세 가지 관문

폴아웃 코믹 스트롱 컴프레스 1200×800 168KB

이 글에서는 EIP-8141을 찬성이나 반대 의견이 아닌 기정사실로 받아들입니다. 목표는 프레임 트랜잭션이 개인정보 보호 프로토콜을 어떻게 개선할 수 있는지, 그리고 이를 실제로 구현하기 위해 공용 멤풀 규칙과 포함 목록 시행 방식에 어떤 변화가 필요한지를 보여주는 것입니다.
피드백을 주신 Carlos , Ben , Milos , Matt 님께 진심으로 감사드립니다!

프레임 트랜잭션( EIP-8141 )은 개인정보 보호 프로토콜에서 릴레이어를 제거할 수 있는 잠재력을 지니고 있습니다. 그러나 공용 멤풀 승인, FOCIL 시행, 그리고 무상태화 로드맵을 규정하는 규칙들은 각각 지원하는 트랜잭션의 범위를 다르게 설정하고 있습니다. 이 글에서는 이러한 경계들이 교차하는 지점과 충돌하는 지점, 특히 개인정보 보호 트랜잭션과 관련된 부분을 분석합니다.

프레임 트랜잭션이 중계기를 제거하는 방법

Tornado Cash 나 Railgun 같은 개인정보 보호 프로토콜은 zk-SNARK를 사용하여 입금자와 출금자 간의 온체인 연결을 끊습니다. 출금 과정에서 머클 트리의 유효한 커밋먼트에 대한 정보를 알고 있다는 사실만 확인하면 되지만, 어떤 커밋먼트인지는 공개되지 않습니다. 문제는 출금자의 주소가 새로 생성된 주소이고, 가스 비용으로 사용할 ETH를 보유하고 있지 않다는 점입니다. 현재는 릴레이어(중앙 집중식으로 운영되고 검열 가능한 제3자, 필요할 때 오프라인 상태인 경우가 많음)가 출금 거래를 대신 처리함으로써 이러한 문제를 해결하고 있습니다.

EIP-8141은 경제성을 변화시킵니다. 프레임 트랜잭션의 VERIFY 프레임은 STATICCALL 로 실행됩니다. 즉, 읽기 전용이며 상태 변경이 없습니다. 결제가 승인되기 전에 VERIFY 원래 상태로 되돌아가면 해당 트랜잭션은 프로토콜 수준에서 무효화되어 블록에 포함되지 않으며 누구에게도 가스 요금이 부과되지 않습니다. 프라이버시 인출은 다음과 같이 됩니다.

• VERIFY 프레임 ( tx.sender = pool 인 경우, 프레임은 풀 자체 저장소를 대상으로 함): SENDER 프레임의 calldata에서 publicInputs를 읽고, 풀에 저장된 기록( SLOAD )과 Merkle 루트를 비교하고, 널리파이어가 사용되지 않았는지( SLOAD ) 확인한 후, 해당 publicInputs에 대해 Groth16 페어링 검사를 실행합니다. 모든 검사를 통과하면 APPROVE 호출합니다.
• SENDER 프레임 : 무효화 항목이 사용되었음을 표시하고, 순 금액을 수신자에게 이체하며, 풀 내의 스폰서 계정에 수수료를 입금합니다.

무엇보다 중요한 것은 수수료를 더 이상 외부 스폰서로부터 조달할 필요가 없다는 점입니다. 인출 자체에서 실행 비용을 지불할 수 있습니다. SENDER 프레임은 인출된 자금의 일부를 가스 비용으로 처리할 수 있으므로, 사전 자금을 보유한 송신자나 제3자 중계자가 필요하지 않습니다. 스폰서의 몫은 풀에 내부 크레딧으로 남아 나중에 청구할 수 있으므로, 인출 시 두 번의 아웃바운드 전송이 아닌 한 번의 아웃바운드 전송만 발생합니다.

스폰서의 위험 부담은 유효하지 않은 증명( VERIFY 되돌리기, 트랜잭션 삭제)의 경우 0이며, 재전송된 증명(널리파이어가 이미 표시됨, VERIFY 되돌리기)의 경우에도 0입니다. 신뢰가 필요 없고, 릴레이어 인프라도 필요 없으며, 추가적인 검열 표면도 없습니다.

포용으로 가는 세 가지 관문

개인정보 보호에 초점을 맞춘 프레임 거래가 검열에 저항하는 경로는 각각 고유한 제약 조건을 가진 세 가지 독립적인 관문을 통과해야 합니다.

1번 게이트: 공용 수영장 입장

EIP-8141의 멤풀 규칙은 ERC-7562를 기반으로 하지만 스테이킹과 평판 기능을 완전히 제거하여 공개 P2P 네트워크를 통해 무엇이 전파될 수 있는지를 정의합니다.

• 유효성 검사 접두사는 인식된 패턴 ( self_verify 또는 only_verify + pay , 선택적으로 deploy 앞에 붙을 수 있음)과 일치해야 합니다.
• SLOAD tx.sender 저장소로만 제한됩니다.
• VERIFY 가스 총량은 MAX_VERIFY_GAS (100,000)로 제한됩니다.
• 금지된 명령어 코드: TIMESTAMP , NUMBER , BLOCKHASH , BALANCE , SELFBALANCE , SSTORE , TLOAD , TSTORE 등
• 정확한 런타임 코드 해시로 식별되는 정식 지급 담당자이며, 시간 제한 출금 및 노드 측 미결제 잔액 추적 기능을 제공합니다.
• 비정규 지급인은 MAX_PENDING_TXS_USING_NON_CANONICAL_PAYMASTER (1)개의 보류 중인 거래로 제한됩니다.

이러한 규칙을 위반하는 모든 항목은 공용 멤풀에서 거부되지만, 대체 멤풀이나 비공개 채널을 통해 개발자에게 전달될 수 있습니다.

2번 게이트: 집중 집행

FOCIL은 거래 포함을 보장합니다. 슬롯당 16명의 IL 위원회 위원이 보류 중인 거래에 대한 자신의 관점을 바탕으로 포함 목록을 작성합니다. 검증자는 IL 거래가 포함된 블록에만 투표하거나 사후 상태에서 해당 거래의 무효성을 입증할 수 있는 경우에만 투표합니다.

EOA의 경우, FOCIL의 누락 검사는 post-state 에 대한 저렴한 nonce / balance 조회입니다. FrameTxs 의 경우, 누락 검사에는 VERIFY 접두사를 다시 재생해야 합니다. 거래 유효성은 발신자 상태뿐만 아니라 실행에도 달려 있기 때문에 저렴한 프록시는 없습니다. FOCIL-frame-txs 제안은 다음 다섯 가지 제약 조건을 통해 적격성을 정의합니다.

1. 유효성 검사 접두사 순서 : VERIFY 프레임은 DEFAULT / SENDER 프레임보다 먼저 와야 합니다.
2. 트랜잭션당 VERIFY 가스 사용량 제한 : verify_gas(tx) <= MAX_VERIFY_GAS_PER_FRAMETX (100,000)
3. IL별 VERIFY 예산 : IL 전체에 걸쳐 누적되는 VERIFY 가스는 MAX_VERIFY_GAS_PER_INCLUSION_LIST (250,000)로 제한됩니다.
4. 기본 거래 유효성 검사 : chain_id , 수수료, 블롭 없음
5. 제한된 상태 접근 : VERIFY AA-VOPS 캐싱에 맞춰 tx.sender 및 payer 계정 상태( balance , nonce , 코드)와 해당 계정의 첫 번째 N 스토리지 슬롯( N =2-4)만 읽을 수 있습니다. 다른 컨트랙트에서 스토리지를 읽으면 해당 트랜잭션은 무효화됩니다.

FrameTxs 어떤 제약 조건도 충족하지 못하면 FOCIL 시행에서 제외됩니다. 따라서 FrameTx의 누락은 건설업체에 불이익을 줄 수 없습니다.

게이트 3: 노드 검증 기능

술어:
PS = 부분적 무상태: 모든 상태가 아닌 일부 상태를 유지하는 것
VOPS = 유효성 검사 전용 PS: EOA에서 전송된 트랜잭션을 검증하는 데 필요한 상태 정보를 유지합니다.
AA-VOPS = VOPS + 계정당 몇 개의 저장 슬롯

ZKEVM 이후에는 노드가 전체 상태를 유지할 필요가 없습니다. 예를 들어 VOPS 노드는 계정당 약 8.4 GB ( nonce , balance , codeHash )만 저장합니다. AA-VOPS는 트라이에서 각 계정에 대해 처음 N 저장 슬롯을 유지함으로써 이를 확장합니다(따라서 일부 tx.sender 및 payer 슬롯은 VERIFY 재실행을 위해 로컬에서 사용 가능합니다). 부분적으로 상태를 유지하는(PS) 노드는 선택된 계약에 대한 저장 공간을 추가로 추적합니다. 노드 유형에 따라 로컬에서 재실행할 수 있는 VERIFY 프레임이 결정되며, 따라서 멤풀에 허용하고 FOCIL과 유사한 포함 목록에 추가할 수 있는 트랜잭션 클래스가 결정됩니다.

특정 트랜잭션 유형을 검증할 수 없는 노드는 해당 트랜잭션을 메모리 풀에 유지할 수 없으며, IL(Interactive Logging)에 포함시켜서도 안 됩니다. 이러한 유형의 트랜잭션에 대한 검열 저항성은 검증 능력이 있는 노드의 비율이 낮아질수록 저하됩니다.

EIP-8141 멤풀 전략을 지원하는 노드 유형에 대한 자세한 분석은 "상태 비저장 관점에서 본 프레임 트랜잭션"을 참조하십시오.

개인정보 보호 거래가 세 가지 관문을 모두 통과하지 못하는 이유는 무엇일까요?

기본 설정에서 개인정보 철회 요청은 세 가지 관문을 모두 통과하지 못합니다.

게이트 1(공용 메모리 풀) : tx.sender = pool 인 경우, VERIFY 프레임의 풀의 Merkle 루트 기록 및 nullifierHashes 매핑에 대한 SLOAD 는 tx.sender 전용 저장 제한을 충족하지만, Groth16 페어링 검사가 EIP-8141 의 유효성 검사 추적 규칙 에 정의된 100k MAX_VERIFY_GAS 제한을 초과합니다. 거부되었습니다.

2단계(FOCIL 적격성) : Groth16 페어링 검사에서 트랜잭션당 100k VERIFY 가스 예산을 초과했습니다. tx.sender = pool 통해 풀의 스토리지를 제한된 상태 접근 규칙에 맞추더라도 가스 한도 초과로 인해 트랜잭션이 부적격 처리됩니다. 따라서 FOCIL 적용 대상에서 제외됩니다.

3단계(노드 기능) : VOPS 및 AA-VOPS 노드는 풀 계약 스토리지를 보유하지 않습니다. 풀을 추적하는 PS 노드 또는 풀 노드만 유효성 검사를 수행할 수 있습니다.

따라서 개인정보 보호 거래는 검열 저항을 위한 모든 기본 경로에서 제외됩니다 . 검열 저항이 가장 절실히 필요한 거래는 현재의 설계로는 보호할 수 없는 거래입니다.

이는 불가피한 것이 아닙니다. 이러한 격차는 FOCIL FrameTxs 포함을 강제하는 방식에서 비롯되며, FOCIL-frame-txs 제안은 강제 가능한 범위에 대해 매우 다른 의미를 갖는 두 가지 접근 방식을 제시합니다. 이 두 가지 중 어느 것을 선택하느냐에 따라 개인정보 보호 관련 FrameTxs 검열에 저항할 수 있는 길이 열릴지 여부가 결정됩니다.

집중 단속: 두 가지 접근 방식

두 접근 방식 모두 동일한 문제를 다룹니다. 즉, 건설업체가 적격한 IL FrameTx 를 검열하지 않았음을 어떻게 입증하는지, 그리고 검증자가 이러한 주장을 어떻게 검증하는지에 대한 문제입니다.

추가 루프 접근 방식

기본 접근 방식은 빌더가 제외된 적격 IL FrameTxs 블록에 반복적으로 추가하여 최종 post-state 에서 누락된 FrameTx 유효하지 않을 때까지 계속합니다. 비용은 제외된 FrameTxs 수에 대해 O(k²) 입니다. 이 2차 빌더 비용으로 인해 MAX_VERIFY_GAS_PER_FRAMETX 는 100_000 , MAX_VERIFY_GAS_PER_INCLUSION_LIST 는 250_000 으로 보수적인 매개변수가 설정됩니다.

공격적인 IL 위원회가 25%(16명 중 4명, 약 한 달에 한 번 발생하며 지분율 1%)이고 트랜잭션 크기가 약 100바이트라고 가정하면, 각 IL은 MAX_BYTES_PER_INCLUSION_LIST ( 8 KiB ) 내에서 약 81개의 트랜잭션을 수용할 수 있지만, IL당 VERIFY 가스 예산은 MAX_VERIFY_GAS_PER_FRAMETX 가스를 사용하여 IL당 2개의 FrameTxs 만 허용합니다( 2 * 100k = 200k <= 250k ). 4개의 악의적인 IL은 k=8 무효 FrameTxs 생성합니다. 추가 루프는 k(k+1)/2 = 36 VERIFY 리플레이를 실행하며, 이는 3.6M 가스(블록의 약 6%)를 소모합니다. 검증자 작업은 4 * 250k = 1M 가스(블록의 약 1.7%)를 소모합니다. 오버헤드는 크지 않지만, 이러한 매개변수로 인해 FOCIL은 FrameTxs 에 대해 사실상 무력화됩니다. MAX_VERIFY_GAS_PER_FRAMETX 100k 로 설정하면 Groth16 증명, PQ 서명 및 기타 복잡한 유효성 검사 로직이 제외되고, MAX_VERIFY_GAS_PER_INCLUSION_LIST 250k 로 설정하면 각 IL에서 최대 2개의 FrameTxs 만 처리할 수 있습니다. 실제로 처리 가능한 FrameTxs 2개뿐인 IL은 계정 추상화를 제대로 강제하지 못합니다.

검증지수 접근법

후속 조치는 추가 루프를 제거합니다. 대신, 빌더는 각 제외된 트랜잭션에 대해 해당 트랜잭션이 무효화된 블록 인덱스를 선언하는 (tx_hash, claimed_index) 쌍을 게시하여 이를 면제합니다 . 검증자는 블록 액세스 목록( EIP-7928 )을 사용하여 claimed_index 에서의 상태를 재구성하고 해당 위치에 VERIFY 접두사를 다시 적용합니다. VERIFY 성공하면 빌더가 거짓을 한 것이므로 해당 블록은 IL 조건을 충족하지 못합니다. 빌더 비용은 O(k²) 에서 O(k) 로 감소합니다. 하지만 프로토콜 복잡성이 증가합니다. 인덱스 클레임은 추가적인 네트워크 구성 요소이며, engine_newPayload IL 트랜잭션과 함께 이를 수용해야 하고, EL은 이에 따라 유효성을 검사해야 합니다.

빌더 비용이 더 이상 병목 현상이 아니므로 MAX_VERIFY_GAS_PER_INCLUSION_LIST 2^20 (약 100만 가스)까지 증가할 수 있으며, 제외된 각 트랜잭션은 반복적으로 검증되는 대신 claimed_index 에서 한 번만 검증되므로 트랜잭션당 가스 제한의 중요성이 줄어듭니다. 2^20 의 트랜잭션당 가스 제한은 개인 정보 보호 프로토콜을 사용하는 트랜잭션이 FOCIL의 검열 저항 보장을 활용하기에 충분히 높습니다.

동일한 25% 공격 시나리오에서 각 IL은 이제 100k 가스로 최대 10개의 FrameTxs 사용할 수 있습니다( 10 * 100k = 1M <= 2^20 ). 악의적인 IL이 4개 있을 경우, 제외되는 FrameTxs 40개입니다. 빌더 비용은 선형적으로 증가하므로 40 * 100k = 4M 가스(블록 비용의 약 6.7%)가 소모됩니다. 어테스터 비용은 4 * 2^20 ≈ 4.2M 가스(블록 비용의 약 7%)입니다. 16개 IL 전체에 대한 최악의 경우: 16 * 2^20 = 2^24 ≈ 16.8M 가스(블록 비용의 약 28%)가 소모됩니다. IL당 예산이 약 4배 증가함에 따라 빌더 비용의 제곱에 비례하는 급증 현상이 완전히 사라집니다.

노드 기능이 제한 요소로 작용함

인덱스 접근 방식은 공용 멤풀 규칙과 FOCIL 시행을 분리합니다. 공용 멤풀 규칙은 트랜잭션이 매 블록 생성 후 재검증이 필요할 수 있으므로 엄격해야 하며, 따라서 상태 의존성은 작고 결정적이어야 합니다. 검증-인덱스 접근 방식의 FOCIL은 고정된 claimed_index 에서 VERIFY 정확히 한 번만 실행합니다. 지속적인 유지 관리 비용이 발생하지 않으므로 더 광범위한 상태 접근과 더 높은 가스 예산을 확보할 수 있습니다. 단점은 FOCIL 검증이 검증자의 핵심 경로( t=4s 검증 마감 시간 내)에 있는 반면, 멤풀 검증은 비동기적으로 실행된다는 것입니다. MAX_VERIFY_GAS_PER_INCLUSION_LIST 값이 높을수록 검증자의 시간 예산이 직접적으로 줄어듭니다.

이는 IL 위원회 구성원이 기본 공개 메모리 풀에 없는 트랜잭션이라도 대체 메모리 풀(개인 정보 보호에 초점을 맞춘 메모리 풀 포함)에서 트랜잭션을 가져와 IL에 포함할 수 있음을 의미합니다. 하지만 개인 정보 보호 트랜잭션에 대해 이 기능이 작동하려면 제한된 상태 접근 규칙(읽기 권한이 tx.sender 및 지불자 계정으로 제한됨)을 완화해야 합니다. 또한 포함을 강제하는 노드는 해당 트랜잭션을 실제로 검증하기 위해 상태 정보가 필요합니다.

AA-VOPS는 이러한 격차를 해소할 수 없습니다. 계정당 N 스토리지 슬롯을 캐시하는데, 이는 간단한 지갑 검증(소유자 키, 논스)에는 충분하지만 개인정보 보호 프로토콜에는 부족합니다. 개인정보 보호 거래 관련 VERIFY 프레임은 송신자 스토리지가 아닌 풀 컨트랙트 스토리지(루트 링 버퍼, 널라이저 매핑)를 읽습니다. N 값을 어떻게 설정하더라도 이 문제는 해결되지 않습니다. 읽기 대상이 완전히 다른 컨트랙트이기 때문입니다. AA-VOPS가 모든 컨트랙트에 대해 N 슬롯을 캐시하더라도 소용이 없습니다. 널라이저 매핑은 해시를 키로 사용하기 때문에 접근하는 슬롯을 예측할 수 없고 스토리지 트라이 전체에 분산되어 있기 때문입니다.

정규 개인 정보 풀

가장 실용적인 해결책은 정규화된 페이마스터 와 유사한 정규화된 풀 패턴입니다. 코드 해시로 식별되는 정규화된 계약은 여러 개인 정보 보호 프로토콜을 위한 공유 레지스트리 역할을 할 수 있습니다. 즉, 풀별로 추가 전용인 머클 루트와 널파이어 세트를 통합되고 감사 가능한 레이아웃에 저장할 수 있습니다. 올바르게 설계된 이러한 풀은 공용 메모리 풀과 FOCIL 시행 모두에 안전합니다. 이 계약을 대상으로 하는 VERIFY 프레임은 호출 데이터에서 파생 가능한 키를 사용하는 acceptedRoots[R] 및 nullifierHashes[h] 라는 두 개의 저장 슬롯만 읽습니다. 접근 패턴은 제한적이고 예측 가능하며 단조롭습니다 . VERIFY가 읽는 모든 슬롯은 항상 false → true 로만 전환됩니다. 노드가 N개의 개별 풀 계약을 추적해야 하는 대신, 정규화된 레지스트리는 문제를 알려진 저장 레이아웃을 가진 하나의 잘 알려진 주소로 축소하여 최소 비용으로 개인 정보 보호를 위한 부분적인 상태 유지를 실현 가능하게 합니다.

단조로운 상태는 설계가 대량 무효화에 강하도록 만드는 핵심 요소입니다. 오늘날의 개인정보 보호 프로토콜은 최근 머클 루트를 저장하는 롤링 링 버퍼를 사용하며, 매번 입금 시 가장 오래된 항목을 제거합니다. EIP-8141에서는 이러한 제거 과정이 대량 무효화 벡터가 됩니다. 단 한 번의 입금(또는 공격자의 스팸)으로 수십 건의 보류 중인 후원 인출이 의존하는 루트가 제거되어 멤풀에서 동시에 모두 사라질 수 있습니다. 링 버퍼를 추가 전용 acceptedRoots 매핑으로 대체하면 이러한 벡터를 완전히 제거할 수 있습니다. 과거의 루트를 기반으로 생성된 인출 증명은 영구적으로 유효합니다. 무효화 세트가 이미 이중 지출을 방지하므로 오래된 루트를 수락하는 것은 암호학적으로 안전합니다. 보류 중인 인출을 무효화할 수 있는 유일한 상태 변경은 특정 nullifierHashes[h] 슬롯에 쓰기를 하는 것이며, 이를 위해서는 노트의 비밀 키를 소유해야 합니다. 이는 트랜잭션별로 개별적으로 적용되며, 대량 공격은 절대 발생하지 않습니다.

한 가지 구현상의 세부 사항은 오늘날의 개인 정보 보호 프로토콜에서 흔히 사용되는 머클 루트용 링 버퍼를 대량 무효화를 방지하기 위해 추가 전용 매핑으로 대체해야 한다는 것입니다. 크기 측면에서 이는 문제가 되지 않습니다. 예를 들어 가장 많이 사용되는 Tornado Cash 계약(1-ETH 풀)에는 81,881건의 예치가 있었습니다. 이는 대략 10.5MB의 원시 키-값 데이터( acceptedRoots 및 nullifierHashes 에 각각 81,881개의 항목, 항목당 약 64바이트)에 해당하며, 상태 트라이에 저장하면 약 25~40MB가 됩니다. 이 풀을 추적하는 PS 노드는 50MB 미만의 추가 상태 데이터를 생성하는데, 이는 약 8.4GB의 VOPS 기준선에 비해 무시할 수 있는 수준입니다.

FOCIL은 슬롯당 16명의 IL 위원회 위원을 배정하므로, 포함을 보장하기 위해 16명 중 1명만 정직한 위원이면 충분합니다. 하지만 여기서 "정직하다"는 것은 "능력이 있다"는 의미도 내포합니다. 프라이버시 트랜잭션을 포함시키고 싶지만 VOPS 또는 AA-VOPS 노드를 운영하는 위원은 해당 트랜잭션을 검증할 수 없습니다. 16명 중 1명만 정직해야 한다는 가정은 16명 중 1명만 능력이 있어야 한다는 가정으로 바뀌게 됩니다. PS 노드는 이 문제를 해결합니다. PS 노드는 전체 상태가 아니라 자신이 관심 있는 계약 정보만 있으면 됩니다. 하나의 주요 프라이버시 풀을 추적하는 PS 노드는 최대 몇 MB의 용량만 추가합니다. 인프라 비용은 무시할 수 있을 정도이며, 관건은 충분한 검증자가 PS 노드를 선택할 것인가입니다.

개인 정보 풀을 정규화하는 대안으로, 트랜잭션 발신자가 최신 상태 루트에 대한 머클 증명과 함께 필요한 상태(저장소)를 첨부하도록 하는 방법이 있습니다. 하지만 이 접근 방식은 여러 가지 이유로 한계가 있는데, 가장 중요한 이유는 이러한 증명이 매 블록마다 무효화되어 지속적으로 재계산해야 한다는 점입니다.

제안된 변경 사항

1. 정규 계약 예외를 개인 정보 보호 풀로 확장합니다. EIP-8141은 이미 런타임 코드 해시 일치를 통해 정규 페이마스터를 허용하고 있으며, 상태 종속성이 알려진 안전성을 가지므로 엄격한 공용 멤풀 규칙에서 면제합니다.
2. 정규 계약 프레임에 대한 트랜잭션당 VERIFY 가스 상한을 높여야 합니다. MAX_VERIFY_GAS = 100_000 Groth16(약 250,000개)에 충분하지 않습니다. 정규 계약은 고정된 검증 경로를 가지므로 최악의 경우 VERIFY 비용은 코드 해시의 고정된 속성입니다. 유효하지 않은 증명도 유효한 증명과 동일한 가스를 소모하고 증폭 없이 폐기됩니다. 일반 프레임에는 100,000을 유지하고, 정규 계약 프레임에는 예를 들어 약 400,000을 허용하여 충분한 여유 공간을 확보하고 메모리 풀에서 해당 프레임 수를 제한해야 합니다.
3. FrameTx 에 대해 보수적인 가스 예산을 강요하는 빌더 오버헤드를 제거하기 위해 프로토콜 복잡성 증가( (tx_hash, claimed_index) 매핑)를 감수하면서 검증 인덱스 FOCIL 강제 적용을 채택합니다 .
4. MAX_VERIFY_GAS_PER_INCLUSION_LIST 2^20 (=1M)으로 높여 , 더 높은 VERIFY 가스(Groth16, PQ 서명)를 사용하는 개별 트랜잭션이 IL별 예산 내에 포함될 수 있도록 합니다.
5. 정규 개인 정보 보호 풀 계약에 대한 제한된 상태 접근 규칙을 완화하여 IL 위원회 구성원이 대체 메모리 풀에서 이러한 트랜잭션을 가져올 수 있도록 하고, 이러한 계약을 추적하는 PS 노드를 실행하는 증명자가 해당 트랜잭션의 포함을 강제할 수 있도록 합니다.

이러한 요소들을 종합하면, 개인정보 보호 FrameTxs 검열 저항성을 확보할 수 있는 실행 가능한 경로를 갖게 됩니다. 즉, 정규 계약 예외에 따른 공개 멤풀 전파, PS 기능을 갖춘 IL 멤버의 포함, 그리고 검증 인덱스 접근 방식을 통한 FOCIL 시행을 통해 비정규 FrameTxs 에 대한 DoS 저항성을 약화시키지 않으면서 이러한 경로를 제공합니다.

양자 컴퓨팅 기반 트랜잭션( PQ)에도 유사한 논리가 적용됩니다. PQ 서명은 크기가 크고 검증 비용이 많이 들며, 10만 VERIFY 가스로는 이를 처리하기에 충분하지 않습니다. 개인 정보 보호 프로토콜과 마찬가지로 PQ 트랜잭션도 검증 계약을 정규화하거나 정규화된 사전 컴파일을 추가하는 방식으로 고정 가스 한도에서 예외를 적용받아야 합니다.

현재 FrameTxs , VOPS 및 AA-VOPS에 대한 공개 멤풀 규칙은 개인 정보 보호 프로토콜에 비해 너무 경직되어 있습니다. 개인 정보 보호 풀을 정규화하면 이러한 문제를 해결할 수 있습니다. 코드 해시를 통해 개인 정보 보호 풀을 식별하면 공개 멤풀에서 해당 풀의 VERIFY 프레임을 안전하게 검증할 수 있으며, 소수의 고가치 계약(개인 정보 보호 풀, 정규화된 결제 관리자)을 추적하는 PS 노드는 해당 풀에 대한 포함 목록을 구축할 수 있습니다. 이를 통해 검열 저항성이 가장 필요한 거래에 대한 보호 기능을 제공할 수 있습니다.

충수

대체 멤풀이 실패하는 이유

• 파편화는 통합을 이루지 못합니다 . 더 엄격한 검증(개인 정보 보호, 품질 보증 등)이 필요한 모든 트랜잭션은 자체적인 대체 메모리 풀을 생성해야 할 수 있습니다. 노드 운영자는 이러한 풀 중에서 가장 성능이 좋은 풀을 선택하고, 이를 지원하는 피어 노드 수는 줄어들며, 가장 취약한 대체 메모리 풀은 해당 풀에 의존하는 모든 작업에 대한 검열 벡터가 됩니다. 내장된 인센티브가 없다면, 대체 메모리 풀은 자발적으로 운영해 줄 자원봉사자에게만 확장성을 부여받게 되며, 심지어는 더 강력하고 값비싼 하드웨어를 구매해야 할 수도 있습니다.
• 익명성 집합 붕괴 : 익명성 집합이 "모든 이더리움 노드"에서 "개인 정보 보호 메모리 풀을 지원하는 노드"로 저하되고, 네트워크 계층에서 피어 연결이 유출됩니다.
• 네트워크 계층에서 손쉽게 검열 가능 : 부트스트랩 노드, DNS 레코드, 단일 목적의 대체 메모리 풀 피어 목록은 ISP나 국가가 단 하나의 규칙으로 차단할 수 있는 병목 지점입니다. 공용 메모리 풀은 전체 네트워크의 부하를 감당하기 때문에 검열하기 어렵지만, 대체 메모리 풀은 그렇지 않습니다. 개인 정보 보호 트래픽은 기존 중계기보다 구조적으로 차단하기 쉬운 인프라를 거치게 됩니다.
• focil의 1/16 보장 가정이 무너집니다 . 적시 포함은 적어도 한 명의 IL 위원회 구성원이 대체 메모리 풀과 피어링 하여 트랜잭션을 검증할 수 있는 경우에만 성립합니다. "16명 중 1명이 정직"이라는 가정은 "16명 중 1명이 정직하고, 구독 중이며, 검증 능력을 갖춘" 것으로 바뀌는데, 이는 EIP-7805 에서 약속한 것보다 훨씬 약한 보장입니다. 특히 IL 빌더가 하드웨어 사양이 낮은 노드로 홍보되는 경우 이러한 문제는 더욱 심각해집니다.
• 릴레이어가 사라지는 것이 아니라 위치가 이동하는 것뿐입니다 . 대체 메모리 풀 트랜잭션은 여전히 빌더에 도달해야 합니다. 경계를 넘어 전달하는 브리징 노드는 바로 트랜잭션 프레임이 제거하고자 했던 신뢰 및 검열 표면이며, 스택에서 한 단계 아래에 위치합니다.

프레임 tx <> 공용 멤풀 결정 트리:

프레임플로우(6) 1040×1000 111KB

정규 개인 정보 보호 풀 예시

표준적인 개인정보 보호 프로토콜 구현 예시(의사 코드 사용)는 여기를 참조하세요.