암호화된 UserOps는 블롭 또는 calldata에 게시된 공개 제약 조건에 포함됩니다. 암호문 옆에는 기본 UserOps의 해시와 이러한 해시가 평문 UserOps의 것임을 증명하는 증거가 공개됩니다.
다음 슬롯 시작 전에 키퍼는 UserOps의 복호화 키를 공개합니다. 제안자는 이제 정렬 선언을 구성해야 합니다.
이 예에서 암호화된 메모리풀은 우선순위 수수료로 정렬합니다. 제안자는 각 UserOp의 우선순위 수수료에 대한 증거를 제공하고 이에 따라 정렬합니다. 제안자는 또한 해시 0xa의 UserOp가 prestate에 대해 무효라고 선언합니다. 제안자는 이제 자신의 블록을 구성해야 합니다.
제안자는 유효한 UserOps를 단일 트랜잭션에 번들링하여 블록 상단에 포함했습니다. 이 트랜잭션 내에서 정렬 선언이 먼저 확인됩니다. 그런 다음 유효한 UserOps 0xb와 0xc가 올바른 순서로 실행됩니다. 이 각각에 대해 유효성 검사가 먼저 수행된 다음 메인 본문이 실행됩니다.
제안자가 해시 0xa의 UserOp가 무효라고 선언했기 때문에 이를 포함하지 않았습니다. 그러나 이제 누구나 0xa가 실제로 유효했다는 증거를 제출하고 이 슬롯의 제안자 팁을 청구할 수 있습니다.
정렬 선언
UserOps가 복호화되면 제안자는 먼저 calldata에 "정렬 선언"을 게시해야 합니다. 이는 제안자가 올바른 순서라고 선언하는 UserOp 해시 목록입니다. 이 목록이 공개 제약 조건에 대해 올바르다는 것이 증명되면 각 UserOp에서 올바른 순서로 포함되었는지 확인하는 데 사용할 수 있습니다.
정렬 선언은 다음과 같아야 합니다:
(1) 메모리풀의 정렬 규칙(예: 우선순위 수수료 또는 FCFS 순서)을 준수해야 합니다.
(2) 원래 제약 조건에 포함되지 않은 UserOps를 포함하지 않아야 합니다.
(3) prestate에 대해 무효였던 제약 조건의 UserOps를 선언해야 합니다.
우리는 (2)를 즉시 확인할 수 있습니다. 선언을 블롭 KZG 약정에 대해 증명된 공개 제약 조건과 비교하면 됩니다. 공개 제약 조건은 UserOps의 해시를 노출해야 합니다(사용자는 제출 시 해시를 증명할 수 있음). 이 해시를 정렬 선언과 비교하여 원래 제약 조건에 포함되지 않은 해시가 없는지 확인할 수 있습니다.
(1)도 즉시 확인할 수 있습니다. 공개 제약 조건의 해시 목록과 정렬 선언을 비교하면 됩니다. FCFS의 경우 목록이 동일해야 합니다. 우선순위 수수료 정렬의 경우 제안자는 각 UserOp의 우선순위 수수료에 대한 추가 증거를 제공해야 합니다.
선언 (3)을 통해 제안자는 일부 UserOps가 유효하지 않아 포함할 필요가 없다고 주장할 수 있습니다. 이를 사전에 증명하는 것은 매우 비싸므로 대신 사후에 사기 증명 게임을 통해 확인할 수 있습니다. 이에 대해서는 포함 섹션에서 자세히 설명하겠습니다.
(1)과 (2)가 온체인에서 증명되면 정렬 선언을 이제 UserOp 정렬 검사에 사용할 수 있습니다.
정렬
UserOp의 본문을 실행하기 전에 다음 사항을 확인해야 합니다:
- UserOp가 정렬 선언과 일치하는 올바른 위치에서 실행되고 있습니다.
- 현재 슬롯이 UserOp에 포함된 슬롯과 일치합니다. SLOT 프리컴파일로 확인할 수 있습니다.
- 번들 트랜잭션이 블록 상단에서 실행됩니다. TXINDEX 프리컴파일로 확인할 수 있습니다.
- 이전 UserOp가 유효성 검사에 실패하지 않았습니다.
이러한 사항이 확인된 경우에만 UserOp의 메인 본문이 실행됩니다. 어떤 검사라도 실패하면 해당 UserOp의 본문과 후속 UserOps의 본문을 실행할 수 없습니다. 제안자는 보상을 청구할 수 없으며 슬래싱될 수 있습니다.
포함
사기 증명 게임을 사용하여 제안자가 공개 제약 조건에서 유효한 트랜잭션을 검열하지 않았음을 확인합니다. 제안자 팁은 스마트 계약에 누적되어 일정 기간 동안 보류됩니다. 이 기간 동안 누구나 제안자가 무효라고 선언한 UserOp가 실제로 prestate에 대해 유효했음을 입증하는 zk 증거를 제출할 수 있습니다. 이 증거를 제출한 사람은 해당 슬롯의 제안자 팁을 청구할 수 있으며 제안자는 슬래싱될 수 있습니다. 보상의 일부 비율을 소각하여 제안자가 자신의 사기 증거를 제출하지 못하도록 할 수 있습니다(슬래싱이 없는 경우). 도전이 제출되지 않으면 제안자가 모든 팁을 청구할 수 있습니다.
대안 설계에서는 제안자가 무효 트랜잭션에 대한 증거를 사전에 제공하도록 강제할 수 있습니다. 이러한 증거를 생성하는 것이 비싸므로 제안자에 대한 괴롭힘 공격으로 이어질 수 있습니다. 따라서 사기 증명 게임을 제안합니다.
고려 사항
종속성
이 제안은 EIP-7793, TXINDEX 프리컴파일에 의존합니다. 다른 합의 수준 변경은 필요하지 않습니다. 번들 트랜잭션이 블록 상단에서 실행되는지 확인하려면 트랜잭션 인덱스가 필요합니다.
EIP-7843, SLOT 프리컴파일은 약한 종속성입니다. 이 프리컴파일을 사용하면 현재 슬롯이 UserOp에 지정된 슬롯과 일치하는지 확인할 수 있습니다. 이것은 엄격한 종속성은 아니며 UserOp에 대신 타임스탬프를 포함하고 TIMESTAMP opcode로 확인할 수 있습니다. 이 접근 방식은 작동하지만 슬롯 길이가 변경되는 경우 업데이트해야 하므로 미래에 대한 대비가 덜 합니다.
ERC-6900 모듈식 스마트 계정이 표준 ERC-4337 계정보다 선호될 수 있습니다. 이러한 계정은 메인 UserOp 본문을 실행하기 전에 실행할 수 있는 사전 실행 후크를 지원합니다.
리오그 안전성
리오그 안전성을 위해 복호화된 UserOps는 공개 제약 조건이 게시된 슬롯 바로 다음 슬롯에 실행되어야 합니다. 이해하려면 제약 조건을 x 슬롯에 게시하고 복호화된 UserOps를 x+2 슬롯에 포함하는 경우를 고려해 보세요. 공격자는 x+2 슬롯에서 UserOps가 복호화될 때까지 기다렸다가 x+1 슬롯에 프론트런닝 트랜잭션이 포함된 블록으로 체인을 리오그할 수 있습니다.
단일 슬롯 완결성이 구현되면 이 요구 사항을 제거할 수 있습니다.
의도 유출
사용자가 암호화된 메모리풀을 통해 토큰 X에서 Y로 큰 스왑을 수행하고 있다고 가정해 보겠습니다. 슬롯의 제안자가 오프라인이므로 복호화된 UserOp가 모두에게 공개됩니다. 앞서 논의한 바와 같이 UserOp의 본문은 향후 슬롯에서 실행될 수 없습니다. 그러나 사용자가 스왑을 수행하려는 의도가 유출되었으므로 다른 사람이 토큰 Y를 선점하여 사용
