Encrypted mempools (2) — 프로젝트 분석
Disclaimer : 서울대학교 블록체인 학회 디사이퍼(Decipher)에서 encrypted mempool을 주제로 Weekly Session에서 발표한 내용을 바탕으로 합니다. 본 아티클은 encrypted mempool의 구현 방법론, encrypted mempool 프로젝트 분석 등에 대한 내용을 다루고 있습니다. 이 보고서에 포함된 어떠한 내용도 투자 조언이 아니며, 투자 조언으로 해석되어서도 안 됩니다.
시리즈
- Encrypted mempools (1) — Encrypted mempools의 등장 배경과 구현방법론
- Encrypted mempools (2) — 프로젝트 분석
Author
문보설, 이솔민 of Decipher
Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)
Reviewed By 박찬우, 박보현
목차
1. Encrypted mempool 구현 시 고려사항
2. TEE방식: SUAVE
3. Threshold 방식: Rolling Shutter
4. Time lock puzzle 방식: Radius
5. 추가 고려사항 — Market Impact
6. 결론
1편에서는 encrypted mempool의 세 가지 구현 방법론에 대해 살펴보았다. 2편에서는 실제 encrypted mempool을 구현하고 있는 프로젝트들에 대해 알아본다. 특히, encrypted mempool을 구현할 때 고려해야 하는 사항들을 선정하여 이를 어떻게 다루고 있는지를 중점적으로 살펴본다.
1. Encrypted mempool 구현 시 고려사항
‘Mempool privacy: An economic perspective’라는 논문은 encrypted mempool 과 같이 mempool privacy를 지키려는 시도가 user와 validator, DeFi market 에 어떤 영향을 미치는지에 대해 분석하고 있다. 이를 바탕으로, 다음과 같은 고려 사항들을 제안해 볼 수 있다.
Validator Incentive Compatibility
블록을 생산하거나, 제안하거나, 복호화에 참여하는 주체들이 의도한 대로 프로토콜에 참여하게끔 해야 한다.
Validator는 블록을 생산하거나, 제안하거나, 디자인에 따라 복호화에 참여하는 역할을 맡을 수 있다. 따라서 여기서의 validator는 블록 생산자, 제안자, 복호화 위원회 등 다양한 역할을 아우르는 개념인 셈이다. 이런 validator는 프로토콜에서 중요한 역할을 담당하기에 이들이 encrypted mempool에 정직하게 참여하는 것은 아주 중요하다. 그러나 때에 따라 validator가 의도한 대로 프로토콜에 참여하지 않는 경우가 생기는데, 다음과 같은 경우가 그 예이다.
프로토콜 참여로 충분한 수익을 얻을 수 없는 경우
‘충분한’ 수익이란 미묘한 개념으로 이를 정량화하는 것은 쉽지 않다. 여기서는 가볍게 1) 수익을 아예 얻을 수 없는 경우나 2) 기존 mempool에 참여할 때보다 수익이 줄어드는 경우 정도로 정의해 보겠다.
1) 수익을 얻을 수 없는 경우
먼저 복호화 위원회와 같은 새로운 주체가 개입될 때, 이들의 수익 구조를 설계할 필요가 있다. 블록 생산자나 제안자와 같은 기존 주체들의 수익을 나눠 가지는 식으로 설계한다면 2)의 경우를, 유저의 수수료를 인상한다면 후술할 user incentive 측면을 고려해야 한다. 이러한 고려 없이 새로운 주체를 도입한다면 아무도 해당 주체를 운영하려 하지 않을 것이고, 결론적으로는 시스템이 제대로 동작하지 않게 된다.
2) 기존 mempool에 참여할 때보다 수익이 줄어드는 경우
블록 생산자나 제안자와 같이 기존 mempool에도 존재했던 주체들에 대해서는 암호화로 인한 이들의 수익 감소를 고려해야 한다. 예를 들어, 암호화된 트랜잭션에 대해서는 MEV를 최대화하는 트랜잭션 정렬 정책을 사용할 수 없다. 따라서 기존 블록 생산자와 같이 MEV를 수익원으로 했던 주체들의 수익이 감소하게 된다. Encrypted mempool은 이런 수익 감소를 상쇄할 또 다른 수익원을 보장해야 한다.
트랜잭션을 미리 복호화할 가능성이 있는 경우
만약 트랜잭션을 복호화한 뒤 트랜잭션 실행 순서를 결정할 수 있다면 이는 encrypted mempool 구현이 의도한 바와 배치된다. 그러나 일부 디자인 방법론은 방법론 자체로 이를 방지할 수 없다. 예를 들어 threshold 방식의 경우, 임계값 이상의 keyper들이 담합하면 미리 트랜잭션을 복호화하여 검열 혹은 악의적인 MEV 공격을 수행할 수 있다. Time lock puzzle의 방식에서도 마찬가지로, 지정한 만큼 복호화가 미뤄진다는 보장은 있지만 복호화 이전에 실행 순서를 결정한다는 보장은 없다. 따라서 복호화가 되기까지 기다렸다가 트랜잭션을 정렬할 가능성이 있다. 실제로 encrypted mempool을 설계할 때는 이러한 위험성을 고려하여, 트랜잭션의 실행 순서가 복호화 전에 결정되며 복호화 후에는 수정되지 않는다는 것을 보장할 방법을 고안해야 한다.
User Incentive Compatibility
Mempool을 이용하는 user가 의도한 대로 프로토콜에 참여하게끔 해야 한다.
User가 encrypted mempool을 구현대로 사용할 것이라는 보장은 없다. User는 암호화에 소모되는 리소스를 줄이기 위해 중간자에게 자신의 plaintext를 보낼 수도 있고, 암호화된 트랜잭션을 이용하여 mempool에 대한 DoS 공격을 수행할 수도 있다.
암호화로 인해 리소스가 많이 소모되는 경우
Encrypted mempool은 실행 전과 후로 암호화와 복호화 과정을 필요로 하며, 구현에 따라 일반적인 mempool보다 실행까지 시간이 더 오래 걸릴 수 있다. 또한 user에게 트랜잭션 암호화의 과정을 요구하기도 한다. User는 이러한 UX 저하에 대해 여러 방식으로 대처할 수 있다. 예를 들어 user는 암호화 과정을 피하기 위해, middleware에게 자신의 트랜잭션을 공개하고 암호화를 맡길 수 있다. 그렇다면 이 middleware가 악의적인 MEV 공격 및 검열을 수행할 수 있게 된다. 혹은 보다 간편하게 encrypted mempool이 아닌 일반 mempool을 이용할 수도 있다. 어느 쪽이든 encrypted mempool의 기획 의도와 배치된다. 따라서 암호화에 필요한 계산적 리소스나 대기 시간 등, user 쪽에서 소모되는 리소스의 양을 줄이는 것이 중요하다.
Mempool에 DoS 공격을 수행할 가능성이 있는 경우
암호화된 트랜잭션의 경우 그 유효성을 확인하기 어렵기 때문에 mempool에 대한 DoS 공격에 사용될 수 있다. 암호화되지 않은 일반적인 트랜잭션의 경우, 트랜잭션을 받은 rpc node가 시뮬레이션을 통해 그 유효성을 확인한 뒤 유효한 트랜잭션만 mempool에 넣게 된다. 이때 시뮬레이션이란 해당 트랜잭션의 서명이나 발신자 잔액 등을 확인하는 과정이다. 이런 시뮬레이션 방식을 통해 유효하지 않은 트랜잭션을 대량으로 보내 mempool 공간을 꽉 차게 만드는 DoS 공격을 방지할 수 있다. 그러나 서명이나 발신자 정보 등 트랜잭션의 내용이 모두 암호화된 트랜잭션의 경우에는 이런 시뮬레이션을 거칠 수 없다. 따라서 user 단에서 mempool에 대한 DoS 공격을 수행할 수 있게 된다. 이러한 공격을 막기 위해, 암호화를 유지하면서 트랜잭션 유효성을 보장하는 방법을 고안할 필요가 있다.
정리하자면, 먼저 validator incentive compatibility 측면에서 1) 프로토콜 참여 시의 수익을 보장하는 것과 2) 트랜잭션의 이른 복호화를 방지하는 것이 중요하다. 또한, user incentive compatibility의 측면에서 1) user의 리소스 소모를 최소화하고 2) DoS 공격을 방지하는 것이 중요하다. 지금부터는 encrypted mempool 구현 방법론별 실제 프로젝트에 대해 알아보고, 이들이 어떻게 위의 고려사항들을 반영하고 있는지에 대해 살펴볼 것이다.’
2. TEE방식: SUAVE
목적
SUAVE는 탈중앙화 블록 빌더 솔루션으로, 다른 체인의 블록 빌딩과 mempool의 역할을 대신할 수 있는 블록체인이다. 알아두어야 할 점은 SUAVE chain의 execution이 오프체인에서 수행된다는 점이다. SUAVE는 블록 빌딩을 위한 블록체인이므로, 여기서 execution이란 MEV-Share, MEV-Boost와 유사한 블록 빌딩 혹은 트랜잭션 번들링을 의미한다. 이러한 execution 알고리즘을 실행하는 주체를 kettle 혹은 execution node라고 부른다.
SUAVE는 kettle의 악의적인 MEV 공격 및 검열을 방지하기 위해 TEE 환경을 사용한다. SUAVE에서 kettle은 목적지 체인의 트랜잭션을 수집 및 관리하는 유일한 주체이다. 따라서 kettle은 목적지 체인의 트랜잭션에 대한 악의적인 MEV 공격 및 검열을 수행할 특권을 얻게 된다. SUAVE는 이를 방지하기 위한 방법으로 kettle을 TEE 환경 내에 구축하고자 한다.
TEE 내부에 목적지 체인의 트랜잭션을 보관하면 TEE 내부에서만 이를 접근할 수 있다. Kettle 노드를 실행하는 kettle 운영자라 하더라도, TEE 내의 복호화된 트랜잭션을 확인하거나 임의로 TEE 내부의 코드를 조작할 수 없다. 따라서 kettle 운영자가 원본 트랜잭션을 이용하거나 블록 빌딩 및 번들링 알고리즘을 조작하여 트랜잭션에 대한 MEV 공격이나 검열을 수행하는 것을 방지할 수 있다.
참고로, 현재까지 구현된 SUAVE는 SUAVE 로드맵에서 Centauri 단계로, TEE 환경은 Andromeda 단계 이후부터 구축될 예정이다. 이 글은 TEE 환경에서의 블록 빌딩과 관련하여 공개된 내용만을 대상으로 한다.
High Level Architecture
SUAVE의 트랜잭션 처리 과정에 대해 알아보기 전에, 먼저 전체적인 SUAVE의 구조를 이해할 필요가 있다. Developer, user, executor의 세 가지 주체가 등장하는데, 각각의 주체가 어떤 역할을 담당하는지에 대해 알아보자.
Developer
Developer는 SUAVE 체인에 컨트랙트를 배포하는 역할을 수행한다. 이때 컨트랙트는 블록 빌딩이나 트랜잭션 번들링 함수를 담고 있다. 예를 들어 아래와 같은 블록 빌딩 코드를 작성하여 배포할 수 있다.
User
User는 preference(혹은 bids)를 confidential data storage로 전송하는 주체이다. 여기서 preference란 목적지 체인으로 가는 트랜잭션으로, EIP-712, intent, user operation 등 다양한 형태를 취할 수 있다. 그리고 confidential data storage란 kettle 내의 데이터 저장소로, TEE 환경 내에서만 접근 가능한 영역이다. 따라서 이 공간에 preference를 전송하면 아무도 preference를 볼 수 없다는 사실이 보장된다.
User는 preference를 보낼 때 자신의 preference에 접근 가능한 contract를 지정할 수 있다. 예를 들어 프론트러닝이나 샌드위치 어택 등의 악의적인 MEV 공격을 수행하는 contract는 접근을 제한하는 식으로 access control을 수행할 수 있다.
Executor
Executor는 앞서 developer가 배포한 블록 빌딩 및 트랜잭션 번들링 컨트랙트를 호출하는 주체이다. 블록 빌딩과 트랜잭션 번들링을 트리거한다는 점에서 MEV-Boost에서의 searcher, builder의 역할을 포괄한다고 볼 수 있다.
트랜잭션 처리 과정
지금부터는 SUAVE의 preference가 블록이 되어 목적지 체인에 도달하는 과정을 알아본다. 아래 그림은 그 과정을 추상화된 형태로 나타낸 그림이다. 점선으로 나타낸 영역은 TEE 내에서만 접근 가능한 암호화된 영역을 나타내며, 가장 큰 점선 박스가 kettle에 해당한다.
1. User가 kettle로 preference를 전송한다.
가장 먼저 user가 kettle 내의 confidential data storage로 자신의 preference를 전송한다. 이때 자신의 preference에 접근 가능한 컨트랙트를 지정할 수 있다. Preference의 내용은 kettle 내의 TEE 환경으로 전달되고, 온체인에는 그 해시값만 기록된다. 또한 그림을 보면, preference가 한번 kettle에 도착한 이후부터는 블록이 될 때까지 TEE 환경(점선)을 벗어나지 않는 것을 알 수 있다. 이러한 장치들을 통해 악의적인 MEV 공격 및 검열로부터 preference를 보호할 수 있다.
2. Executor가 번들링 컨트랙트를 호출한다. [MEV-Share]
1을 통해 수집한 preference들을 번들링 하는 과정은 기존 MEV-Share와 유사하다.
먼저 kettle 내의 preference를 처리하여 hint를 만들어낼 수 있다. Hint는 preference의 내용을 전부 유추할 수는 없지만, 어떤 종류의 preference인지 정도는 알 수 있는 정보 조각을 말한다. 예를 들어 어떤 contract와 상호작용하는지에 대한 정보가 hint가 될 수 있다. 추출된 hint는 온체인에 emit된다.
Executor는 공개된 hint를 보고, 자신의 미완성 bundle과 함께 배포되어 있는 번들링 컨트랙트 중 하나를 호출하는 트랜잭션을 보낸다. 이 트랜잭션은 hint를 만족하는 preference를 자신의 미완성 bundle에 끼워 완성된 bundle을 만들어 달라는 요청에 해당한다.
Executor의 트랜잭션이 실행 단계에 도달하여 kettle에게 전달되면 컨트랙트에 정의된 대로 번들링이 진행된다. 그 결과 완성되는 트랜잭션 번들은 여전히 kettle 안에 보관되며, 트랜잭션 번들에 대한 해시값만이 실행의 결과로 온체인에 기록된다.
3. Executor가 블록 빌딩 컨트랙트를 호출한다. [MEV-Boost]
2를 통해 완성한 트랜잭션 번들을 블록으로 만드는 과정은 기존 MEV-Boost와 유사하다.
먼저 executor는 배포되어 있는 블록 빌딩 컨트랙트 중 하나를 호출하는 트랜잭션을 보낸다. Executor의 트랜잭션이 실행 단계에 도달하면, kettle이 컨트랙트에 정의된 대로 블록을 생성한다. 여기서 번들 간의 충돌이 발생했을 때의 해결 방법이나, 동일한 트랜잭션을 포함하는 블록이 여러 개 생성될 가능성에 대한 논의는 아직 공개되지 않았다.
4. 완성된 블록을 수수료와 함께 목적지 체인에 제출한다.
마지막으로, 3에서 완성된 블록을 목적지 체인에 제출하는 단계이다. 현재는 MEV-Boost와 유사하게 릴레이가 이 단계를 수행하고 있다. 그러나 앞으로 PBS 및 stateless ethereum이 도입되어 1) builder가 블록 유효성을 증명하는 방법과 2) 프로토콜 자체에서 proposer와 builder 사이의 약속을 이행시키는 방법이 고안된다면 릴레이는 제거될 수 있다.
분석
Validator Incentive Compatibility
수익 보장
앞서 살펴본 트랜잭션 처리 과정에서 핵심적인 역할을 하는 주체에는 kettle, executor, 목적지 체인의 proposer가 있다. 먼저 executor는 MEV-Boost에서 builder, searcher로 동작할 때와 같은 수익원을 유지할 수 있다. 트랜잭션 번들링을 하는 경우 MEV를 추출할 수 있고, 블록 빌딩을 하는 경우 트랜잭션 수수료를 받을 수 있다. 다음으로 목적지 체인의 proposer는 MEV-Boost에서와 마찬가지로 블록과 함께 제출된 bid를 수익으로 가져갈 수 있다. 마지막으로 ketttle의 경우 어떻게 수익을 얻을 수 있는지 발표되지 않았다. 한 가지 생각해 볼 수 있는 가능성은 SUAVE의 트랜잭션 수수료이지만, suave-specs 문서를 보면 그 가능성은 낮아 보인다. 수수료 자체가 낮아 kettle과 SUAVE chain node가 이를 나눠 가져서 충분한 수익을 볼 수 있을지가 의문이기 때문이다. Kettle 실행 요청을 Confidential Compute Request라고 하는데, 문서에 따르면 이에 지불되는 수수료는 소액의 정액 요금이며 이 수수료로 오프체인 컴퓨팅을 제한 없이 사용할 수 있다고 한다. 실행 비용과 관계없이 낮은 수준의 정액 요금이 부과된다는 점에서 이 수수료가 kettle에게 돌아가기는 어려워 보인다.
정리하자면 전체적으로 MEV-Boost의 수익 구조가 그대로 유지되며, kettle의 수익만 SUAVE 트랜잭션 수수료의 일부로 보장된다는 것을 알 수 있다. 이때 수수료 수취 대상이 되는 트랜잭션이 바로 executor의 트랜잭션이기 때문에, executor의 수익을 해치지 않는 선에서 수수료를 부과할 수 있도록 할 필요가 있다.
복호화 방지
앞서 살펴보았듯, preference는 TEE 환경 내에서만 접근 가능한 구조이며 실행이 되어 블록에 담기기 전까지는 TEE 환경을 벗어날 수 없다. Kettle 외부에서 복호화된 트랜잭션을 확인하거나 TEE 내부 코드를 수정하는 것이 불가능하므로, 악의적인 MEV 공격이나 검열을 수행할 수 없다.
User Incentive Compatibility
리소스 최소화
앞서 살펴본 트랜잭션 처리 과정에서, user는 1) 자신의 preference를 암호화하는 리소스와 2) TEE 내부에서 처리되는 시간을 소모해야 한다. 구체적으로 어느 정도인지 공개되지는 않았지만, flashbots가 수행한 “Block building inside SGX”라는 프로젝트에서 2)의 리소스 소모량을 추측할 수 있다.
“Block building inside SGX”는 MEV-Boost의 빌더를 SGX 내부에서 실행하는 프로젝트이다. 성능 측정 결과, SGX 환경에서 실행한 빌더를 mgasps(million gas per second, 초당 가스 처리량)으로 나타냈을 때 150 mgasps로 측정되었다고 한다. 이는 non-SGX 환경에서 실행한 빌더 대비 2배 낮은 성능으로, 똑같은 크기의 블록을 만드는 데에 SGX 환경 빌더가 non-SGX 환경 빌더 대비 2배의 시간이 걸린다는 것을 의미한다. 이는 TEE 환경에서 프로그램을 실행하면서 발생하는 반복적인 암호화 및 복호화로 인한 오버헤드로 추측된다.
정리하자면 TEE 내부에서 트랜잭션 번들링 및 블록 빌딩 알고리즘을 실행시키는 것은 많은 오버헤드를 발생시킨다. 이러한 리소스 소모는 목적지 체인의 블록 제안 시간 내에 블록을 생산할 수 없는 결과 뿐만 아니라 유저 경험을 저해하는 결과를 불러일으키므로, 개선이 필요하다고 할 수 있겠다.
DoS 공격 방지
Kettle은 블록 빌딩을 위해 목적지 체인의 상태 정보를 모두 들고 있으며, kettle을 운영하는 당사자는 복호화된 트랜잭션을 볼 수 없지만 kettle sgx 내에서는 트랜잭션 복호화가 가능하다. 이는 곧 kettle 내에서 트랜잭션 유효성을 시뮬레이션하는 것이 가능하다는 것을 의미한다. 따라서 kettle 내에서 트랜잭션 유효성 검증 프로그램을 실행하고, 유효성 검증을 통과하지 않는 트랜잭션은 confidential data storage에 넣지 않는다면 user의 DoS 공격을 방지하면서도 user의 트랜잭션을 보호할 수 있다.
3. Threshold 방식: Rolling Shutter
목적
Rolling shutter는 shutter network에서 진행하는 프로젝트의 종류로, L2에 encrypted mempool을 통합하는 것을 목적으로 한다. 현재는 OP grant를 받아 OP stack에 encrypted mempool을 구현하는 프로젝트를 진행 중이다. Rolling shutter는 중앙화된 sequencer의 검열과 MEV 문제를 threshold encryption으로 해결하고자 한다. 중앙화된 sequencer는 트랜잭션 실행에 대한 권한을 독점하므로, L1보다 더 심각한 MEV 공격과 검열을 수행할 수 있다. 따라서 키퍼라는 위원회를 두고 일정 임계값 이상의 키퍼 동의 하에서만 트랜잭션 복호화가 이루어지게끔 하는 것이다. 키퍼들이 트랜잭션 실행 순서가 결정된 이후에만 복호화에 동의한다고 가정하면, 한두명의 악의적인 키퍼가 트랜잭션을 복호화하는 것은 불가능하게 된다.
트랜잭션 처리 과정
1) User는 암호화 키로 트랜잭션을 암호화하여 sequencer에게 전송한다.
가장 먼저 user는 자신의 트랜잭션을 암호화하여 sequencer에게 전송한다. 이때 사용되는 암호화 키는 키퍼들이 만들어서 공개한 키로, 복호화 키는 키퍼들만 복구할 수 있다. 암호화 키와 복호화 키는 DKG(Distributed Key Generation)으로 만들어지는데, 매 블록마다 DKG를 수행하면 키 생성에 드는 오버헤드가 크다. 이유를 간단히 설명하자면, DKG는 모든 참여자가 각자가 계산한 값을 다른 참여자들과 공유한 뒤 그 값들을 합쳐 최종 키를 생성하는 방식으로, 여러 번의 통신을 필요로 하기 때문이다. 이러한 통신 오버헤드 때문에 여기서는 epoch-specific한 암호화 키를 만들고, 이 암호화 키와 블록 넘버와 같은 부가 정보를 결합하여 block-specific한 암호화 키를 도출하는 방법을 이용한다.
2) Sequencer는 암호화된 트랜잭션의 실행 순서와 실행 컨텍스트를 결정한 뒤 서명한다.
다음으로 sequencer는 암호화된 트랜잭션의 실행 순서와 실행 컨택스트를 결정한다. 실행 컨택스트란 트랜잭션이 실행될 블록 넘버나 타임스탬프 등을 의미한다. 이렇게 실행 컨택스트가 결정되면 이 정보에 서명을 한 뒤, 컨트랙트에 서명을 올린다. DAO는 이 서명과 실제 실행 순서를 대조하여 서로 다른 경우 sequencer를 슬래싱한다.
3) Keyper는 트랜잭션의 실행 컨택스트에서 복호화 키를 생성한다.
매 블록마다 키퍼들은 해당 실행 컨택스트에서 실행되어야 하는 트랜잭션에 대한 복호화 키를 생성한다. 임계값 이상의 키퍼들이 투표에 참여하면 복호화 키가 생성되며, 이 키를 sequencer에게 전달하게 된다. 만약 일부 악의적인 키퍼들이 담합하여 복호화 키를 미리 생성한다면 DAO에 의해 키퍼에서 퇴출된다.
4) 블록의 맨 앞에서 트랜잭션을 실행한다.
복호화 키를 받은 sequencer는 트랜잭션을 복호화 한 뒤, 블록의 맨 앞에서 해당 트랜잭션을 실행한다. 블록의 맨 앞에서 트랜잭션을 실행하는 이유는 프론트러닝을 방지하기 위함이다. 즉, 블록의 앞 부분은 암호화된 트랜잭션 실행에 할당하고, 뒷 부분은 일반 트랜잭션의 실행에 할당하는 것이다.
분석
Validator Incentive Compatibility
수익 보장
앞서 살펴본 트랜잭션 처리과정에서 핵심적인 역할을 수행하는 주체는 키퍼, sequencer, DAO이다. Optimism Collective에 올라온 글에 따르면, 이 주체들의 수익은 모두 유저의 수수료를 인상하는 방식으로 보장될 것으로 보인다. 어느 정도를 인상할 것인지에 대해서는 공개된 바가 없지만, ShutterDAO에 올라온 글을 보면 최소 어느 정도의 비용이 드는지는 추측할 수 있다.
먼저 sequencer의 비용부터 따져 보면, 암호화된 트랜잭션의 경우 암호화로 인해 calldata 비용이 일반 트랜잭션 대비 37.5% 정도 증가한다고 한다. 다음으로 키퍼의 경우 최소 50대의 키퍼가 필요한데, 이들을 운영하는 총 비용을 암호화된 트랜잭션을 이용할 것으로 보이는 트랜잭션들로 나누면 트랜잭션 당 6센트 정도의 비용이 필요하다고 한다.
위 정보는 비용, 즉 수수료의 최소 인상 수준을 의미하므로, 이 정도 수수료 인상으로는 앞서 살펴본 ‘수익을 아예 얻을 수 없는 경우’을 벗어날 수 없다. 말하자면 키퍼와 sequencer의 손익분기점인 셈이다. 특히 키퍼의 경우에는 수익을 얻을 수 있는 수단이 수수료밖에 없기 때문에, 이 외에 어떻게 추가적인 수익을 얻을 수 있을 것인지에 대한 논의가 필요한 상황이다.
복호화 방지
키퍼가 트랜잭션을 미리 복호화하거나, sequencer가 약속한 순서가 아닌 임의의 순서로 트랜잭션을 실행할 가능성이 있다. Shutter network는 이것을 DAO의 모니터링 로직으로 방지한다. 앞서 트랜잭션 처리과정의 2)번에서 언급했듯이, sequencer가 암호화된 트랜잭션에 대해 약속한 순서가 아닌 순서로 트랜잭션 실행을 제공한다면 DAO에서 이를 보고 슬래싱하는 로직이 갖춰져 있다. 따라서 슬래싱을 피하기 위해, sequencer는 약속한 순서대로 트랜잭션을 실행해야 한다. 다음으로 3)에서 살펴보았듯, 키퍼가 미리 복호화 키를 생성한다면 이 역시 DAO에 의해 저지된다. DAO는 키퍼 셋에서 악의적인 키퍼나 담합을 하는 키퍼를 제거할 권한을 가지고 있기 떄문이다. 그러나 앞서 수익 보장 측면을 살펴보았을 때, DAO의 수익에 대한 내용은 나와있지 않았다. DAO의 수익 구조가 미약하여 키퍼 혹은 sequencer가 DAO의 구성원들을 매수할 수 있다면 DAO의 모니터링 로직은 유명무실하다. 따라서 무엇보다도 수익 구조를 명확히 하는 것이 중요하다고 할 수 있겠다.
User Incentive Compatibility
리소스 최소화
Rolling shutter의 구조상, 복호화 및 암호화 자체에는 많은 시간이 걸리지 않지만 암호화된 트랜잭션이 반드시 다음 블록에서 복호화된다는 문제가 있다. 이는 앞 블록에서 sequencer가 실행 순서를 온체인에 커밋하고, 최소 그 다음 블록부터 복호화 및 실행이 이뤄지기 때문이다. 즉 암호화된 트랜잭션은 일반 트랜잭션 대비 2배의 딜레이가 필요한 것이다. 이 부분은 유저 경험을 해칠 수 있기 때문에 논의가 필요할 것으로 보인다.
DoS 공격 방지
암호화된 트랜잭션의 유효성을 어떻게 판단할 것인지에 대해서는 논의가 많이 이뤄지지 않은 상황이다. Optimism collective에 올라온 글의 future considerations를 보면, 트랜잭션 유효성 증명에 ZKP를 활용할 수 있다는 언급이 있기는 하나, 구체적은 사항은 알려지지 않았다. 어떻게 user side에서 리소스 소모적인 ZKP를 효율적으로 생성할 수 있을 것인지와 user가 stateless한 상황에서도 트랜잭션 유효성을 증명할 수 있을지 등에 대한 더 많은 논의가 필요할 것으로 보인다.
4. Time lock puzzle 방식: Radius
목적
Radius는 encrypted mempool을 제공하는 shared sequencing layer로, 중앙화된 sequencer로 인한 MEV 및 검열 문제를 encrypted mempool로 해결하고자 한다. Radius에서 사용하는 방법은 time lock puzzle 방식으로, 트랜잭션 복호화 키를 생성하기 위한 일부 매개변수들(time lock puzzle)을 전달하여 복호화 키 생성 시간 동안 트랜잭션 실행을 미룰 수 있게 한다.
High level architecture
Radius의 트랜잭션 처리 과정에는 transaction encryption과 PVDE(Practical Verifiable Delayed Encryption), order commitment의 세 구성요소가 등장한다. 순차적인 트랜잭션 처리 과정을 알아보기 전에, 각 요소의 등장 배경과 원리에 대해 알아보자.
Transaction encryption
Radius는 대칭키 암호화를 사용하여 트랜잭션을 암호화한다. 먼저 user는 대칭키를 생성하여 트랜잭션을 암호화한 뒤, sequencer에게는 대칭 키 생성에 필요한 매개변수와 함께 전달한다. 이 매개변수를 time lock puzzle이라고 하고, 이 매개변수들을 이용하여 대칭 키를 생성하는 과정을 ‘time lock puzzle을 푼다’라고 한다.
Sequencer가 암호화된 트랜잭션을 복호화하기 위해서는 user가 암호화에 사용한 것과 동일한 대칭키가 필요하다. 그런데 대칭 키 생성을 위해서는 반드시 일정 횟수의 순차적인 연산을 수행해야 하므로, 일정 시간 동안은 암호화된 트랜잭션의 원본을 볼 수 없다는 것이 보장된다. 이때 매개변수를 어떻게 설정하느냐에 따라 대칭 키 생성에 걸리는 시간이 달라지므로, user 입장에서 복호화를 지연할 기간을 조절할 수 있다. Sequencer는 대칭 키 생성 프로세스를 시작함과 동시에 트랜잭션의 실행 순서를 결정하여 블록을 만든다. 이후 대칭 키가 생성되면 트랜잭션을 복호화하여 실행한 후 그 결과를 이더리움에 제출한다.
이 과정만 떼어 놓고 살펴보면 두 가지 가정이 존재한다. 첫째는 선의의 user 가정으로, (1) user가 만든 time lock puzzle이 유효하다는 가정과 (2) 복호화된 트랜잭션 역시 유효할 것이라는 가정이다. 먼저 (1)의 가정은 user가 제시한 time lock puzzle을 풀면 암호화된 트랜잭션을 복호화할 수 있는 대칭 키가 생성된다는 것이다. 만약 user가 유효하지 않은 time lock puzzle을 제시한다면 sequencer는 time lock puzzle을 푸는 데에 리소스를 낭비하게 된다. 다음으로 (2)의 가정은 복호화된 트랜잭션이 트랜잭션의 유효성 검증(simulation)을 통과한다는 것이다. 위와 같은 구조에서 만약 user가 유효하지 않은 트랜잭션을 보낸다면, 해당 트랜잭션을 그대로 블록에 포함시켜야 하므로 블록 공간이 낭비되는 결과가 초래된다.
둘째는 선의의 sequencer 가정으로, (1) seqeuncer가 트랜잭션의의 순서를 결정하는 시점은 대칭 키가 생성되기 이전이라는 가정과 (2) 대칭 키 생성 이전에 결정한 트랜잭션의 순서를 생성 이후에 변경하지 않는다는 가정이다. 만약 sequencer가 대칭 키를 생성한 후 트랜잭션 생성 순서를 결정하거나 임의로 변경한다면, 트랜잭션의 내용을 모두 알 수 있으므로 검열 저항성과 나쁜 MEV 방지라는 원 목적을 달성할 수 없다.
정리하자면 위 프로세스는 선의의 user와 선의의 sequencer를 가정하고 있는 셈이다. Radius는 이러한 가정을 제거하기 위해 암호학적인 방법을 도입하는데, 바로 앞으로 살펴볼 ZKP(PVDE)와 order commitment이다.
PVDE: 악의적인 user 방지
먼저 첫 번째 가정, 즉 선의의 user 가정을 없애기 위해 ZKP를 사용한다. User가 전달하는 트랜잭션과 time lock puzzle이 유효하다는 것을 증명하기 위해, 추가적으로 ZKP(Zero-Knowledge Proof)를 전달하는 것이다. 이때 ZKP는 다음과 같은 것들을 보장한다.
- Time lock puzzle의 해답인 공개 키가 암호화된 트랜잭션의 복호화 키이다.
- 암호화가 정확하게 실행되었다.
- 트랜잭션의 nonce와 서명은 유효하며 sender의 계정 잔액이 트랜잭션 수수료를 충당할 수 있다. (즉, 트랜잭션이 유효하다.)
이러한 과정을 통과하는 트랜잭션을 우연히 찾는 것은 슈바르츠-지펠 레마에 의해 불가능에 가깝다는 것이 알려져 있다. 그렇다면 함께 온 ZKP가 검증을 통과한다면 위 사항들을 모두 만족하는 트랜잭션과 time lock puzzle이 도착했다는 것을 확신할 수 있는 것이다. 따라서 sequencer는 제공된 proof가 검증을 통과하는지 확인하여 앞서 제시된 악의적인 user의 가능성을 차단할 수 있다. 이렇게 time lock puzzle과 유효성 증명을 함께 전달하는 방식을 PVDE(Practical Varifiable Delay Encryption)이라고 하며, 보다 수학적인 내용은 Radius에서 작성한 포럼 글에서 찾아볼 수 있다.
Order commitment: 악의적인 sequencer 방지
다음으로 두 번째 가정, 즉 선의의 sequencer 가정을 없애기 위한 노력을 알아보자. 이 부분에 대한 최적화를 위해 많은 논의가 이루어지고 있으나, 최근 나온 글에는 아래와 같은 내용이 소개되어 있다.
Radius는 선의의 sequencer 가정을 없애기 위해 order commitment와 order validation 과정을 도입한다. Order commitment란 트랜잭션 실행 순서에 대한 약속이다. Sequencer는 트랜잭션의 실행 순서를 결정한 뒤, user에게 user의 트랜잭션이 블록의 어디에 위치할 것인지를 commitment로 만들어 전달한다. Order commitment를 받은 user는 다음과 같은 두 가지 사실을 보장받을 수 있다.
1) Sequencer가 복호화 키 생성 이전에 트랜잭션 순서를 결정했다.
Order commitment를 받은 user는 (commitment를 받은 시점) — (트랜잭션을 보낸 시점) < (Time lock puzzle을 푸는 데에 걸리는 시간) 가 성립하는지 여부를 확인한다. 만약 이 수식이 성립하지 않는다면, 즉 user가 트랜잭션을 보낸 이후로 order commitment를 받기까지 걸린 시간이 time lock puzzle을 푸는 데에 걸리는 시간보다 길다면 sequencer가 복호화 키 생성 이후 order commitment를 만들었을 가능성이 있다. 반대로 order commitment를 받기까지 걸린 시간이 time lock puzzle보다 짧다면, sequencer가 복호화 키 생성 이전에 order commitment를 만들었다는 사실을 확신할 수 있다. 따라서 order commitment는 그 도착 시점을 통해 sequencer가 복호화 키 생성 전에 order를 정했다는 사실을 보장할 수 있다.
2) Sequencer가 복호화 키 생성 이후 약속한 순서를 변경하지 않는다.
User는 이후 실제 트랜잭션 실행 순서를 order commitment와 대조해 보고, 다를 경우 claim을 통해 이의를 제기할 수 있다. Claim이 제기되면 컨트랙트에서 user가 받은 order commitment가 실제 execution에 사용된 order와 다른지를 trustless하게 검사할 수 있다. 그 결과 sequencer가 악의적이었다고 판명되면, sequencer를 slashing한다. 따라서 order commitment는 sequencer가 복호화 이후 실행 순서를 변경하지 않는다는 사실을 보장할 수 있다.
트랜잭션 처리 과정
앞서 구조를 설명하면서 살펴본 트랜잭션 처리 과정을 시간 순서로 간략하게 짚고 넘어가자.
1. User는 sequencer에게 암호화된 트랜잭션과 time lock puzzle, ZKP를 전달한다.
먼저 user는 대칭키를 생성하여 트랜잭션을 암호화한 뒤, time lock puzzle과 함께 sequencer에게 전달한다. 이 과정에서 ZKP도 만들어서 전달하는데, 이는 1) time lock puzzle의 유효성과 2) 트랜잭션 유효성을 증명하기 위한 절차이다.
2. Sequencer는 트랜잭션 실행 순서를 결정하고, order commitment를 전달한다.
다음으로 sequencer는 대칭 키 생성 알고리즘을 시작시킨 후, 알고리즘이 실행되는 동안 트랜잭션 실행 순서를 결정한다. 그 결과를 order commitment 형태로 user에게 전달하는데, 이는 트랜잭션 실행 순서에 대한 약속과 같다. 이를 바탕으로 user는 1) sequencer가 복호화 키 생성 이전에 실행 순서를 약속했고 2) 복호화 키 생성 이후 실행 순서를 조작하지 않을 것임을 보장받을 수 있다.
3. Sequencer는 트랜잭션을 실행하고 그 결과를 L1에 제출한다.
마지막으로 sequencer가 대칭 키를 얻고 나면, 트랜잭션을 약속한 순서대로 실행하고 그 결과를 L1에 제출하게 된다. User는 L1에 제출된 실행 순서와 order commitment를 대조하여 실제로 sequencer가 복호화 키 생성 이후 실행 순서를 조작하지 않았다는 것을 확인할 수 있다.
분석
Validator Incentive Compatibility
수익 보장
트랜잭션 처리 과정에서 핵심적인 역할을 담당하는 주체는 sequencer이다. Sequencer는 트랜잭션 암호화로 인해 MEV를 최대화하는 정렬 정책을 사용할 수 없게 되므로, MEV 수익이 줄어들 수 있다. 따라서 이렇게 줄어든 수익을 상쇄할 방법이 필요하다. Radius에서는 아래와 같은 block design을 통해 sequencer 수익을 보장할 뿐만 아니라, 아비트라저들의 백러닝도 가능하게끔 하는 구조를 설계했다.
위 구조에서 sequencer는 트랜잭션 암호화로 포기해야 했던 MEV 수익을 block space auction을 통해 상쇄할 수 있다. 먼저 블록의 아래에 유저의 트랜잭션을 넣고, 블록의 위쪽 공간은 MEV auction을 위해 남겨둔다. 그리고 user들의 트랜잭션의 순서를 결정하고 대칭키를 생성하는 동안, 동시에 아비트라저들을 대상으로 위쪽 공간에 대한 경매를 벌인다. 이때 같은 블록의 아랫부분에 존재하는 user의 트랜잭션은 암호화되어 있으므로 프론트러닝으로부터 보호를 받을 수 있다. 대신, 이전 블록의 아랫부분에 존재하는 트랜잭션은 공개되어 있으므로 아비트라저들은 이 트랜잭션에 대한 백러닝으로서 block space를 구매할 수 있다. 경매를 통해 벌어들인 bid는 sequencer의 몫이 되므로, 줄어든 MEV 수익을 상쇄할 수 있는 것이다. 또한, 이러한 구조는 MEV로 수익을 얻고 싶어하는 아비트라저와 같은 주체들에게 백러닝을 가능하게 한다는 장점도 제공한다. 뒤에서 살펴볼 market impact 측면에서 두 블록 공간의 용도를 뒤바꿀 수도 있다.
복호화 방지
복호화 방지 측면에서는 order commitment가 중요한 역할을 수행한다. 먼저 order commitment의 도달 시점을 기준으로 복호화 이전에 트랜잭션 순서를 결정했는지를 확인할 수 있다. 또한, 복호화 이후에 트랜잭션 순서를 조작할 가능성은 order commitment를 이용한 claim으로 방지 가능하다. 이렇게 order commitment가 중요한 역할을 수행하지만 보다 효율적인 방법에 대해 더 많은 논의가 이루어지고 있는 것으로 보인다.
User Incentive Compatibility
리소스 최소화
User가 만들어야 하는 것들 중 ZKP가 가장 리소스 소모적이다. Radius는 이 시간을 1초 가량으로 줄였다고 하며, 특히 time lock puzzle의 복잡도와 관계 없이 항상 circuit을 일정하게 유지하는 방법을 고안했다고 한다. 이 외에도 stateless한 상태에서의 트랜잭션 유효성 증명 방법 등 여러 가지 리소스 최적화를 위한 방법을 고민하고 있는 것으로 보인다.
DoS 공격 방지
앞서 살펴보았듯 Radius는 트랜잭션 유효성을 ZKP를 이용해 증명한다. 따라서 sequencer는 ZKP 검증이 통과하지 않는다면 해당 트랜잭션을 거부하는 방식으로 DoS 공격을 방지할 수 있다.
그러나 한 가지 우려되는 점은 딜레이 매개변수 설정과 관련한 mempool 공간 낭비이다. 앞서 언급했듯이 user는 딜레이에 관련된 매개변수를 조정하여 복호화 키 생성에 걸리는 시간을 조정할 수 있다. 이 시간은 ‘mempool에 트랜잭션이 존재할 것으로 예상되는 시간 + 트랜잭션 실행 직전까지 걸리는 시간(순서 결정, commitment 확인 등)’ 정도가 될 것이다. 하지만 mempool에 트랜잭션이 머무는 시간은 네트워크 상황에 따라 변동적이므로 예측하기 쉽지 않다. 트랜잭션을 자주 보내본 사람이라면 알겠지만, 에어드랍 등의 이벤트로 인해 갑자기 가스비가 치솟는 경우 예상치 못하게 트랜잭션이 mempool에 계속 머물게 되는 상황이 발생한다. 이처럼 갑자기 많은 트랜잭션이 발생하여 예상보다 더 오랜 시간 트랜잭션이 mempool에 머물게 되는 상황을 생각해 보자. 이러한 트랜잭션들은 mempool에 머무는 동안 이미 매개변수만큼의 시간이 지나 유효하지 않은 트랜잭션(순서 결정 전에 복호화된 트랜잭션)이 될 가능성이 있다. 이러한 상황은 딜레이 암호화를 활용하는 방법론을 설명할 때 항상 언급되는 문제점이며, radius에서도 활발한 논의가 이루어지고 있는 것으로 보인다.
5. 추가 고려사항 — Market Impact
지금까지는 프로토콜 구성 주체들과 일반 user들에게 미치는 영향을 중심으로 encrypted mempool을 구현할 때의 고려사항에 대해 알아보았다. 그러나 프로토콜 생태계를 구성하는 Dapp들에게 미치는 영향도 충분히 고려되어야 한다. 이 글에서는 Mempool Privacy 논문을 바탕으로, DeFi 청산로직에 미치는 영향을 하나의 예로 살펴보도록 한다.
문제
랜딩 프로토콜의 포지션이 최소담보비율에 도달하면 이 포지션을 빠르게 청산시키는 것이 중요하다. 그렇게 하지 않으면 담보가치가 하락함에 따라 프로토콜이 악성 부채를 떠안을 위험이 있기 때문이다. 따라서 랜딩 프로토콜은 이 포지션을 할인된 가격으로 팔아 청산자들이 경쟁적으로 사가도록 한다. 일반적인 mempool에서는 보통 하나의 블록 내에서 최소담보비율 도달과 청산이 동시에 일어난다. Mempool에 어떤 포지션을 최소담보비율에 도달시키는 트랜잭션이 있는지 보고, 경쟁적으로 청산 트랜잭션을 제출하면 되기 때문이다. 이렇게 빠르게 청산이 일어나는 것을 효율적인 청산 알고리즘이라고 할 수 있다. 반면, encrypted mempool의 경우 포지션을 최소담보비율에 도달시키는 트랜잭션이 mempool에 존재하는지 알 수 없다. 트랜잭션이 실행 전까지 모두 암호화되어 있기 때문이다. 따라서 포지션이 최소담보비율에 도달한 그 다음 블록에서야 청산이 이뤄질 수 있고, 이러한 청산 알고리즘의 비효율성은 최소담보비율을 올리게 하므로 자본효율성을 낮추는 결과를 불러일으킨다. 뿐만 아니라, solana의 optimistic transaction과 같이 낙관적인 추측에 의거해 트랜잭션을 보내는 아비트라저들이 발생해 네트워크 혼잡도가 올라갈 수도 있다.
블록 디자인의 중요성
이러한 측면에서 블록 디자인에 관심을 가질 필요가 있다. 예를 들어 Radius의 블록 디자인에서 오른쪽과 같이, 블록의 위 아래 용도를 바꿀 수 있다고 한다.
오른쪽 구조를 취하는 경우, user의 트랜잭션이 복호화 된 이후 block space auction이 일어난다. 아비트라저들은 블록에 어떤 트랜잭션이 포함되는지를 보고, 포지션을 최소담보비율에 도달시키는 트랜잭션이 있는 경우 이를 청산시키는 트랜잭션을 제출할 수 있다. 그 결과 앞서 살펴본 청산 알고리즘의 비효율성을 개선할 수 있게 된다. 그러나 단점은 블록 생성에 걸리는 시간이 늘어난다는 것이다. 왼쪽 구조에서는 복호화 키 생성, 트랜잭션 순서 결정, block space auction의 세 프로세스를 동시에 실행할 수 있다. 반면 오른쪽 구조에서는 복호화 키 생성과 트랜잭션 순서 결정의 두 프로세스만 동시에 실행 가능하고, block space auction 프로세스는 그 다음부터 실행되어야 한다. 이처럼 여러 상황을 고려하고 각 구조의 장단점을 비교하면서 블록 공간을 디자인하는 것이 중요하다.
6. 결론
지금까지 encrypted mempool의 구현 방법론을 소개하고, 실제 구현체를 분석하면서 encrypted mempool을 구현할 때 고려해야 하는 사항들에 대해 알아보았다.
Encrypted mempool은 MEV와 검열로부터 사용자의 트랜잭션을 보호할 수 있는 강력한 수단 중 하나이며, 크게 세 가지 분류로 나뉠 수 있다. 먼저 TEE라는 특수한 하드웨어 환경을 이용하여 블록에 포함되기 전까지 사용자 트랜잭션을 보호하는 방법이 있다. 또한, 실행 순서가 결정되기 전까지 복호화를 방지하기 위해, 여러 위원회가 복호화 키를 나눠 가지거나, time lock puzzle과 같은 시간 지연 암호화를 이용하는 방법도 있다. 이때, 각 방법론 자체의 신뢰 가정과 장단점들을 이해하고 상황에 맞게 선택하는 것이 중요하다고 할 수 있다.
실제로 많은 프로젝트에서 각자의 필요에 따라 encrypted mempool을 구현하고 있다. 특히 Flashbots와 같이 MEV 추출과 관련한 새로운 서비스를 제공하고자 하는 경우 혹은 Radius, Rolling shutter와 같이 중앙화된 시퀀서의 악의적인 MEV 및 검열을 방지하고자 하는 경우에 encrypted mempool을 이용할 수 있다. 실제 구현은 validator와 user 각각의 인센티브와 호환되어야 하는데, 이는 encrypted mempool 구현 방법론 자체로 보장되는 것은 아니므로 설계 단계에서 충분히 고려되어야 한다. 예를 들어 validator의 수익 보장 방법이나 복호화를 방지하는 방법, 그리고 user의 리소스 및 UX 최적화와 DoS 방지 방법 등을 고려하여 encrypted mempool을 구현할 필요가 있다. 추가적으로, validator와 user의 인센티브 뿐만 아니라 DeFi 등 블록체인 생태계를 구성하는 서비스들에게 미치는 영향도 고려할 필요가 있다.
Encrypted mempool은 암호화를 이용하여 사용자 트랜잭션에 대한 접근을 원천적으로 차단하는 매력적인 솔루션이다. 그러나 앞서 설명한 현실적인 문제들을 제대로 극복하지 못한다면 오히려 프로토콜에 참여하는 주체들의 장애물 및 블록체인 서비스 구현의 비효율을 낳을 수 있다. 다행스러운 점은, 구현체 분석 과정에서 많은 프로젝트들이 이러한 문제를 인식하고 개선을 위해 노력하고 있다는 사실을 확인할 수 있었다는 점이다. 앞으로 이러한 노력들이 이어져 encrypted mempool이 mempool privacy의 핵심적인 요소로 주목받기를 기대한다.
참고자료
Encrypted Mempools — by Jon Charbonneau — Jon’s Newsletter
https://arxiv.org/pdf/2307.10878.pdf
Block Building inside SGX | Flashbots
The MEVM, SUAVE Centauri, and Beyond | Flashbots
https://writings.flashbots.net/the-future-of-mev-is-suave/
SUAVE ideal functionality and TEE-design research questions
https://github.com/flashbots/suave-specs
https://medium.com/fourpillars/mev-share-유저들을-위한-mev-재분배-메커니즘-d68806be228a
https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg
MEV-resistant ZK-Rollups with Practical VDE (PVDE) — Layer 2 — Ethereum Research
https://hackmd.io/@zeroknight/radius_decentralizing_rollup_sequencers
Shutterized Beacon Chain — Execution Layer Research
https://www.umbraresearch.xyz/writings/mev-on-solana#optimistic-transactions
