이 스레드는 이더리움에 스키마에 구애받지 않는 암호화된 메모리 풀을 추가하는 이더리움 개선 제안(EIP) (수량 미정)에 대한 논의를 위한 것입니다. 전체 내용은 다음과 같습니다.
추상적인
이 이더리움 개선 제안(EIP) 암호화된 멤풀을 프로토콜에 내장하는 것을 제안합니다. 이를 통해 사용자는 트랜잭션이 블록 에 포함될 때까지 암호화할 수 있으므로, 프론트 러닝(Front Running) 및 샌드위치 공격으로부터 트랜잭션을 보호하고 검열 저항성을 강화할 수 있습니다. 이 설계는 임의의 복호화 키 제공자를 지원하므로 암호화 기술에 구애받지 않습니다. 예를 들어 스레스홀드(Threshold) 암호화, MPC 위원회, TEE, 지연 암호화 또는 FHE 방식 등을 사용할 수 있습니다. 기존의 평문 트랜잭션도 계속 지원되며, 복호화 키 제공자가 실패하더라도 블록체인의 진행이 보장됩니다.
동기 부여
이 이더리움 개선 제안(EIP) 의 목표는 악의적인 거래 순서 변경 공격을 방지하고 프로토콜의 실시간("약한") 검열 저항성을 높이는 것입니다. 또한 블록 생성자 및 기타 프로토콜 참여자의 신원을 일시적으로 숨김으로써 규제 위험을 줄이는 것을 목표로 합니다. 이 목표는 거래가 결국 공개되므로 사용자 개인정보 보호(예: 거래 기밀성)를 개선하는 것이 아닙니다.
이 제안은 셔터라이즈드 비콘 체인(Shutterized Beacon Chain) 및 노시스(Gnosis) 체인(Gnosis Chain) 에 이미 배포된 암호화된 멤풀의 실제 프로토콜 외 구현과 같은 기존 연구를 기반으로 합니다. 이는 오랜 문제였던 프론트 러닝(Front Running) 를 해결하고, 빌더 중앙 집중화와 같은 MEV의 부정적인 2차 효과를 완화할 가능성을 가지고 있습니다. 또한, 이 설계는 제안자와 빌더의 분리(ePBS) 원칙과 자연스럽게 부합하여 이더리움 로드맵의 논리적인 확장이라고 할 수 있습니다.
사양
실행 계층에서는 키 제공자 레지스트리라는 계약이 배포됩니다. 이 레지스트리를 통해 모든 계정은 키 제공자를 등록하고 고유 ID를 할당받을 수 있습니다. 등록 시에는 복호화 함수와 키 유효성 검사 함수를 포함하는 계약을 지정해야 하며, 각 함수는 바이트 문자열 형태의 키 ID와 키 메시지를 인수로 받습니다. 또한, 키 제공자는 다른 제공자를 직접 신뢰 대상으로 지정하여 방향성 신뢰 그래프를 형성할 수 있습니다. 키 제공자 A가 다른 키 제공자 B를 신뢰하는 것은 이 그래프에서 A에서 B로 향하는 방향성 경로가 존재하는 경우에만 해당합니다. 비콘 체인은 비콘 체인 예치금 처리 메커니즘과 유사하게 키 제공자 레지스트리의 상태를 복제합니다.
암호화된 트랜잭션이 새로운 트랜잭션 유형으로 추가되었습니다. 암호화된 트랜잭션은 봉투(envelope)와 암호화된 페이로드(payload)로 구성됩니다. 봉투에는 봉투 논스), 가스량, 가스 가격 매개변수, 키 제공자 ID, 키 ID 및 봉투 서명이 지정됩니다. 암호화된 페이로드에는 페이로드 논스, 값, 호출 데이터 및 페이로드 서명이 포함됩니다.
유효한 블록 에서 키 제공자 A의 키로 암호화된 모든 트랜잭션은 다음 트랜잭션 앞에만 올 수 있습니다.
평문 거래
키 제공자 A의 키로 암호화된 거래
A가 신뢰하는 키 제공자의 키로 암호화된 거래
각 슬롯에서 키 제공자는 빌더가 게시한 실행 페이로드를 관찰하면 자신의 키 제공자 ID로 주소가 지정된 모든 암호화된 트랜잭션의 봉투에 참조된 키 ID를 수집합니다. 그리고 각 키 ID에 대해 해당 복호화 키 또는 키 보류 알림을 게시해야 합니다. 해당 메시지에는 향후 슬롯에서 재실행을 방지하기 위해 비콘 블록 해시 참조됩니다. 키 제공자는 실행 페이로드를 관찰하는 즉시 또는 슬롯의 나중 시점으로 게시를 지연할 수 있습니다.
페이로드 적시성 위원회(PTC) 구성원은 키 제공자 ID 및 키 ID 필드로 식별되는 모든 암호화된 트랜잭션에서 참조되는 복호화 키를 수신해야 합니다. 이들은 레지스트리 계약에 명시된 유효성 검사 함수를 사용하여 이러한 키를 검증해야 하며, 키당 하드코딩된 소액의 가스 한도를 사용해야 합니다. 마지막으로, 이들은 페이로드 증명 메시지에서 각 암호화된 트랜잭션에 대한 유효한 키의 존재 여부를 증명해야 하며, 이 메시지는 이 목적을 위해 전용 비트필드가 추가되어 있습니다.
실행 페이로드 처리 과정에서 모든 평문 트랜잭션이 완료된 후, 암호화된 트랜잭션의 봉투(envelope)가 일괄 처리됩니다. 이 과정에서 봉투 서명자의 논스(nonce)가 업데이트되고 봉투 계정에서 수수료가 지급됩니다. 수수료에는 봉투, 복호화된 페이로드, 복호화 키에 사용된 블록 공간 비용과 복호화 및 키 유효성 검사에 사용된 연산 비용이 포함됩니다. 이후, 봉투에 지정된 키 제공자 ID와 키 ID를 사용하여 키 제공자 레지스트리의 복호화 함수를 통해 암호화된 페이로드가 복호화됩니다. 복호화가 성공하면, 봉투에 지정된 가스 한도와 블록 가스 한도에 따라 해당 페이로드 트랜잭션이 실행됩니다. 복호화 또는 실행이 실패하거나, PTC에서 복호화 키가 없는 것으로 확인되는 경우를 포함하여, 해당 트랜잭션은 봉투를 되돌리지 않고 건너뛰어집니다.
이론적 해석
주요 제공자 등록
등록 과정은 암호화 기술에 구애받지 않도록 설계되어 프로토콜의 중립성을 보장하고, 새로운 키 제공자의 진입 장벽을 최소화하며, 사용자가 목적에 맞는 최적의 방식을 선택할 수 있도록 합니다. 실행 계층 계약은 임의의 실행 로직을 명시하는 표준적인 방법으로 선택되었습니다. 실행 계층 계약에서만 등록하는 방식 또한 합리적인 대안입니다.
많은 암호화 방식은 이더리움 가상 머신(EVM) 에서 표현하기에 비효율적이므로 별도의 사전 컴파일이 필요합니다. 하지만 이러한 사전 컴파일을 추가하는 것은 본 이더리움 개선 제안(EIP) 의 범위를 벗어납니다.
주요 공급자 신뢰 그래프
암호화된 거래를 전송하는 사용자는 자신의 키 제공자뿐만 아니라 블록 에 포함된 이전 거래에 사용된 모든 키 제공자도 신뢰해야 합니다(보안 고려 사항 참조). 프로토콜은 사용자의 신뢰 선호도를 존중해야 하지만, 각 사용자가 자신의 키 제공자만 신뢰하는 경우 블록 생성자는 각 블록 에 단 하나의 키 제공자의 키로 암호화된 거래만 포함할 수 있습니다. 이는 시장 점유율이 낮은 키 제공자가 경쟁하기 어렵게 만들고 키 제공자 독점을 초래할 위험이 있으므로 바람직하지 않습니다.
반면, 사용자가 신뢰하는 제3자 제공업체를 명시적으로 지정하도록 요구하면 거래 크기가 커지고, 충족해야 할 사용자 선호도가 많아져 블록 생성 과정이 더욱 어려워질 수 있습니다. 따라서 본 제안은 절충안으로 키 제공업체가 이러한 선택을 하도록 요구합니다. 사용자는 키 제공업체의 키를 사용함으로써 암묵적으로 이에 동의하는 것입니다.
이 솔루션을 사용하면, 단일 지배적인 키 제공자로 구성된 준독점 체제가 나타나고 해당 키 제공자가 다른 키 제공자를 신뢰할 만한 것으로 지정하지 않더라도, 소규모 키 제공자들이 주요 키 제공자를 신뢰하는 한(그리고 잠재적으로 서로를 신뢰하는 한), 개발자는 기회비용 없이 다른 소규모 키 제공자를 사용하는 트랜잭션을 포함할 수 있습니다.
거래 주문
이 제안은 블록을 평문 거래 부분과 암호화된 거래 부분으로 효과적으로 분리합니다. 평문 거래를 먼저 배치함으로써 블록 생성자는 이 부분의 실행을 완벽하게 시뮬레이션하고 기존 블록 생성 기술 및 MEV 추출 전략을 적용할 수 있습니다. 따라서 블록 생성자는 기회비용 없이 암호화된 거래를 블록 끝에 추가할 수 있습니다. 순서가 반대로 되면 암호화된 거래를 포함하는 블록이 평문 거래만 포함하는 블록에 비해 PBS 경매에서 경쟁력을 갖추려면 암호화된 거래에 대한 수수료가 상당히 높아야 할 것입니다.
거래 실행
프로토콜과 블록 생성자 모두 가스 비용을 지불할 수 없는 암호화된 거래가 생성되는 것을 방지해야 합니다. 블록 내 암호화된 페이로드의 내용과 관계없이 이를 보장하기 위해, 수수료 지불은 평문 봉투에 포함되며, 블록 내 모든 봉투는 암호화된 페이로드보다 먼저 실행됩니다. 가스 환불은 지급되지 않으므로 블록 생성 시 블록 생성자와 프로토콜이 받을 수수료 금액을 보장합니다.
간단하게 설명하기 위해 암호화된 페이로드에는 서명이 포함됩니다. 개인 정보 보호 측면에서는 다소 떨어지지만 더 효율적인 대안은 봉투 서명자를 발신자로 간주하는 것입니다.
복호화 키 보류
이 프로토콜은 복호화 키 제공자가 원하는 조건에 따라 복호화 키를 보류할 수 있도록 명시적으로 허용합니다. 이를 통해 제공자는 사용자의 키 사용 권한을 제한하는 규칙을 안전하게 구현할 수 있습니다. 예를 들어, 이전 결제 내역을 기반으로 키 ID 프론트 러닝(Front Running) 공격을 방지할 수 있습니다(보안 고려 사항 참조). 반면, 정당한 이유 없이 보류된 키는 사용자 지정 슬래싱 메커니즘 및 신뢰성 측정에 사용될 수 있습니다(프로토콜은 어떤 키가 현재 존재하는지, 과거에 존재했던 적이 있는지, 그리고 존재하지 않았던지를 기록합니다).
프로토콜 내 주요 의료 제공자 인센티브 부족
이 제안은 키 제공자에 대한 수수료 메커니즘이나 부정행위에 대한 처벌 조항을 명문화하지 않습니다. 따라서 다양한 인센티브 모델을 오프체인에서 구현할 수 있습니다. 예를 들어, 키 제공자는 빌더와 계약을 체결하거나, 사용자로부터 거래 건당 보수를 받거나, 공공재로서 활동할 수 있습니다. 또한, 키 제공자가 정당한 이유 없이 키를 제공하지 않을 경우 슬래싱) 조건을 적용하여 서비스를 더욱 매력적으로 만들 수도 있습니다.
실행 페이로드 암호화
향후 이더리움 개선 제안(EIP) 빌더가 키 제공자로부터 키를 받아 실행 페이로드를 암호화할 수 있도록 하는 방안이 제안될 수 있습니다. 이를 통해 빌더는 실행 페이로드를 생성 직후 바로 공개할 수 있으며, 기존에는 50% 슬롯 시점에만 공개했습니다. 이는 P2P 효율성을 높이고 시스템 충돌로 인한 슬롯 누락으로부터 빌더를 보호할 수 있습니다. 또한, 빌더가 블록 에 사용된 키에 대한 영지식 증명을 첨부하는 경우, 키 공개 시점을 앞당겨 더 길게 설정할 수 있습니다. 하지만 복잡성을 최소화하기 위해 이 기능은 현재 이더리움 개선 제안(EIP) 에는 포함되지 않았습니다.
하위 호환성
이 제안은 실행 및 합의 계층의 프로토콜에 하위 호환성을 깨뜨리는 변경 사항을 포함합니다.
보안 고려 사항
신뢰할 수 있는 키 제공업체
사용자는 거래를 암호화하는 데 사용하는 키 제공자를 반드시 신뢰해야 합니다.
복호화 키를 조기에 공개하지 않음으로써 프론트 러닝(Front Running) 및 샌드위치 공격을 방지합니다.
복호화 키를 늦게 공개하여 봉투 수수료가 지불되기 전에 거래 실행을 방해하지 않도록 합니다.
키 제공자는 암호화 메커니즘(예: 스레스홀드(Threshold) 암호화, 하드웨어 암호화), 경제적 메커니즘(예: 부정행위에 대한 슬래싱 ), 거버넌스 메커니즘(예: 사회적으로 평판이 좋은 주체를 선택하기 위한 투표) 또는 이러한 메커니즘의 조합을 통해 신뢰를 얻을 수 있습니다.
사용자는 블록 내에서 자신의 거래 이전에 사용된 모든 암호화된 거래에 사용된 키 제공자를 신뢰해야 합니다. 이는 키 제공자가 복호화 키를 공개하거나 보류할 수 있는 옵션을 가지고 있기 때문입니다. 키 제공자는 후속 거래의 복호화 키를 확인한 후 해당 키를 가져갈 수 있습니다. 이러한 옵션을 통해 후속 거래의 사전 상태에 어느 비트(Bit) 영향을 미칠 수 있습니다. 악의적으로 선택된 "복호화" 방식은 조작된 복호화 키를 사용하여 복호화 결과의 특정 부분을 직접 수정하거나 아예 설정함으로써 이 공격을 훨씬 더 강력하게 만들 수 있습니다. 이는 사실상 선행매매 (프론트 러닝(Front Running) 가능하게 합니다.
사용자는 자신의 거래 이후에 포함된 거래에 사용되는 키 제공자를 신뢰할 필요가 없습니다. 왜냐하면 사용자의 거래 페이로드의 사전 상태는 이후 거래의 페이로드에 영향을 받지 않기 때문입니다(단, 봉투는 영향을 받지만, 봉투는 복호화 키가 게시되기 전에 선택됩니다). 마찬가지로, 평문 거래 사용자도 어떤 키 제공자도 신뢰할 필요가 없습니다(단, 키 생성자는 계속 신뢰해야 합니다).
재조직
복호화 키는 해당 암호화된 거래가 확정되기 전에 공개됩니다. 따라서 체인 재구성(reorg)이 발생할 경우, 거래가 체인에 포함되지 않더라도 공개될 수 있습니다. 하지만 복호화 키 메시지에는 블록 해시 포함되어 있으므로 키 유효성 검사 기능을 통해 무효화할 수 있습니다. 이는 봉투 거래의 체인 포함 자체를 막지는 못하지만, 실행을 방지하여 페이로드의 프론트 러닝(Front Running) 를 막을 수 있습니다.
키 ID 프론트 러닝(Front Running)
사용자가 특정 키 ID로 거래를 암호화할 때, 다른 사용자가 해당 거래를 실시간으로 관찰하고 동일한 키 제공자와 키 ID를 지정하는 또 다른 암호화된 거래를 생성할 수 있습니다. 두 번째 거래가 원래 거래보다 이전 블록 에 포함되면, 경험이 부족한 키 제공자는 해당 키를 노출시켜 원래 거래가 아직 블록에 포함되지 않았더라도 원래 거래 내용을 확인할 수 있습니다.
키 제공업체는 이러한 공격으로부터 사용자를 보호할 수 있습니다. 한 가지 가능한 전략은 키 ID에 "네임스페이스"를 적용하는 것입니다. 제공업체는 봉투 서명자의 주소로 시작하는 키 ID에 대한 키만 공개하고 나머지는 모두 공개하지 않습니다. 공격자가 봉투 서명자 계정에 접근할 수 없다고 가정하면, 공격자는 올바르게 네임스페이스가 적용된 키 ID를 사용하여 거래를 생성할 수 없습니다.
주요 공급자-아동 양육업자 담합
새로운 블록 생성하려면 블록 생성자는 이전 블록 의 생성 후 상태, 즉 블록 에 사용된 모든 복호화 키와 보류된 키를 알아야 합니다. 이 정보는 PTC(Project Token Certification)에서 인증하면 공개적으로 알 수 있습니다. 그러나 악의적인 키 제공자가 블록 생성자와 공모하여 정보를 미리 제공할 수 있습니다. 이렇게 되면 블록 생성자는 블록 생성 프로세스를 더 빨리 시작할 수 있어 경쟁 우위를 확보하게 됩니다.
공격의 영향은 미미한 것으로 판단되는데, 페이로드 인증 게시 시점과 해당 슬롯 종료 시점 사이의 시간이 블록 생성에 충분한 시간이기 때문입니다. 또한, 블록 생성 기간의 시작 부분은 종료 부분보다 훨씬 덜 중요합니다(종료 시점에야 포함 가능한 모든 트랜잭션을 알 수 있기 때문입니다). 종료 시점은 공격의 영향을 받지 않습니다. 더불어, 복호화 키 공개를 지연시키면 PTC(Public Trade Center)에서 해당 키를 인증하지 않을 위험이 있어 공격자의 경쟁 우위를 상쇄할 수 있습니다. 마지막으로, 악의적인 키 제공자를 사용하는 암호화된 트랜잭션 수가 적다면, 트리 상태에 미치는 영향 또한 미미할 가능성이 높습니다. 따라서, 트리 상태에 대한 완전한 정보에 의존하지 않는 낙관적 블록 생성 전략이 공격에 대응할 수 있는 효과적인 전략이 될 수 있습니다.
