애플리케이션 제어 실행: 취소 우선순위 지정에 대한 사례 연구

애플리케이션 제어 실행: 취소 우선순위 지정에 대한 사례 연구

메리엄 과 마이크 작성 - 2026년 1월 29일.

요약: 애플리케이션 제어 실행(ACE)은 애플리케이션에 트랜잭션 순서 제어 권한을 부여하는 메커니즘입니다. Hyperliquid의 취소 우선순위 기능은 현재 ACE의 가장 주목할 만한 사례이며, 온체인 거래를 크게 개선할 수 있음을 보여줍니다. 이 글에서는 ACE 구현을 위한 네 가지 제안된 메커니즘과 각각의 메커니즘이 취소 우선순위 기능을 어떻게 구현할 수 있는지 분석합니다. 또한 스마트 계약 언어로 구현되고 L1 합의 알고리즘에 의해 강제될 수 있는 보다 일반적인 형태의 ACE에 대해서도 살펴봅니다. 이러한 패러다임 내에서, 블록 생성 복잡성 증가와 구성 가능성 감소라는 구체적인 단점을 예시를 통해 보여줍니다. 이 글의 궁극적인 목표는 다양한 형태의 ACE에 대한 논의를 정리하는 것입니다. 이를 통해 이러한 설계 방식에는 많은 공통점이 있으며, 취소 우선순위 기능처럼 강력한 기능도 큰 복잡성 없이 구현될 수 있음을 보여주고자 합니다.

내용물

(1) 서론
(2) 기존 설계
\쿼드 (2.1) 앱 체인
\쿼드 (2.2) 범용 체인에서의 배치 처리
\쿼드 (2.3) 오프체인 당사자에 의한 배치 처리
\쿼드 (2.4)프로토콜에 의해 강제되는 제안자 약속
(3) 합의에 의해 강제되는 앱 지정 순서
\쿼드 (3.1) 블록 구성 복잡성
\쿼드 (3.2) 구성 가능성
\쿼드 (3.3) 거래 메타데이터
(4) 결론

관련 기사

(1) 서론

이 논문은 애플리케이션 제어 실행(ACE)에 대해 연구합니다. ACE란 애플리케이션이 자신과 상호 작용하는 트랜잭션의 순서에 제약 조건을 지정할 수 있는 상태를 말합니다. 본 논문에서는 ACE를 다음과 같이 정의합니다.

애플리케이션 제어 실행은 해당 애플리케이션과 상호 작용하는 트랜잭션 배치에 순서 규칙을 적용합니다.

배치(batch)의 구성 요소를 정의하는 것은 애플리케이션의 몫이지만, 지금은 가장 자연스러운 선택인 블록당 하나의 배치에 초점을 맞추겠습니다. ACE는 매우 광범위한 개념이자 정의이므로, Hyperliquid에서 구현한 취소 우선순위 지정에 초점을 맞춰 구체적으로 설명하겠습니다. 취소 우선순위 지정에 대한 다음 정의를 사용하겠습니다.

취소 우선순위는 각 배치 내에서 취소 주문이 접수 주문보다 우선하도록 합니다.

Hyperliquid의 설명 에 따르면, "취소 주문과 체결 전용 주문은 GTC 및 IOC 주문보다 우선순위가 높습니다." (주문 유형에 대한 설명은 여기를 참조하세요.) 편의상, 여기서는 거래를 체결하지 않고 거래소에서 유동성을 제거하는 주문을 "취소 주문"으로, 거래를 체결하는 주문을 "체결 주문"으로 정의하겠습니다. 거래소의 세부적인 사항(예: DEX인지 온체인 CLOB인지)은 대부분 생략하지만, 필요한 경우 예시를 통해 명확히 설명하겠습니다.

제2절 에서는 ACE 구현을 위한 네 가지 기존 설계 방식을 살펴보고 각 방식의 장단점을 분석합니다. 서로 다른 설계 방식을 통합하기 위해, 원래 제안이 특정 사용 사례에 국한된 것은 아니지만, 취소 우선순위 지정 작업을 구체적으로 연구합니다.
섹션 3에서는 스마트 계약이 함수 순서를 지정하고 합의 알고리즘이 상태 전이 함수에서 해당 순서를 강제하는 보다 일반적인 프로토콜 내 ACE 구현을 살펴봅니다. 이러한 "고정된" 솔루션에는 두 가지 단점이 있습니다. 바로 블록 생성 복잡성 증가와 구성 가능성 감소입니다. 이 두 가지 단점을 보여주는 간단한 예제를 제시합니다.

(2) 기존 설계

다음 네 개의 하위 섹션에서는 ACE 구현을 위한 다양한 제안 메커니즘을 간략히 설명하고 각 메커니즘이 취소 우선순위 지정을 어떻게 구현할 수 있는지 제시합니다. 모든 메커니즘을 다루지는 않지만, 각 설계의 주요 장단점을 분석합니다.

(2.1) 앱 체인

취소 우선순위 기능을 최초로 구현한 암호화폐 프로젝트는 하이퍼리퀴드(Hyperliquid)였습니다. 제프는 이 결정의 동기를 여기에서 설명하며, 거래소 거래량은 다소 감소하겠지만(거래량은 종종 허영 지표로 여겨짐) 이러한 결정이 사용자에게 더 좁은 스프레드를 제공하는 데 도움이 된다고 주장했습니다. 하이퍼리퀴드는 거래에 특화된 앱 기반 L1 거래소이기 때문에 프로토콜 수준에서 이러한 설계 방식을 구현했습니다.

"이 순서는 L1 자체에서 온체인 방식으로 강제됩니다. Hyperliquid L1에서 노드가 블록을 실행하는 유일하게 올바른 방법은 취소 및 게시 전용 주문을 먼저 처리하는 것입니다."
– 하이퍼리퀴드의 디자인 .

이는 애플리케이션별 순서 규칙을 적용하는 가장 간단하고 강력한 방법입니다. 아래 순서도는 이러한 흐름을 보여줍니다. "합의에 의한 적용"은 블록 검증 단계에서 발생하며, 이 단계에서 증명자들은 취소(Cancel)가 실행(Take)보다 먼저 발생하는지 확인하여 블록의 유효성을 판단합니다.

upload_ebca492ec3e2ad44731712d27495d28c 1070×1276 76.8 KB

취소 우선순위 지정을 위한 앱 체인의 장점:

• 세밀한 제어: 앱 체인의 특성상, 애플리케이션은 실행 환경에 대한 최대한의 제어권을 갖습니다. 각 앱 체인이 블록 생성 및 검증 방식을 제어할 수 있도록 하는 것은 코스모스 생태계의 오랜 기조였습니다(다만, 이러한 독립적인 도메인 간의 상호 운용성은 아직 실현되지 않았습니다). 앱 체인이 블록 공간을 생성하는 다른 방식들도 있습니다. 예를 들어, Injective는 블록 생성 속도에 맞춰 빈번하게 배치 경매를 진행합니다. 각 트랜잭션을 순차적으로 처리하는 대신, 일괄적으로 동시에 실행합니다. 마찬가지로, dYdX는 투표 확장 기능을 사용하여 블록 제안자가 제외할 수 있는 트랜잭션 집합을 제한함으로써 블록 제안자의 권한을 제한합니다( FOCIL 과 매우 유사한 설계 방식입니다).

취소 우선순위 지정을 위한 앱 체인의 단점:

• 검열 저항성: 하이퍼리퀴드 순서 지정 규칙(및 일반적으로 앱 체인 커밋먼트)의 견고성은 체인과 검증자 집합의 검열 저항성만큼만 강력합니다. 제안자는 블록에서 취소 부분을 완전히 제외함으로써 언제든지 취소가 아닌 실제 거래를 실행할 수 있습니다. 이렇게 하면 취소로 인한 거래 수수료 수익을 포기하게 되지만, market maker 1 제안자에게 뇌물을 줄 의향이 있다면 합리적인 선택일 수 있습니다.
• "브리징 전용" 정산: 본 분석에서 "정산"은 거래가 포함된 시점과 해당 거래의 결과물이 범용 L1 블록체인의 다른 애플리케이션에서 사용될 수 있는 시점 사이의 지연 시간으로 정의합니다. 하이퍼리퀴드(Hyperliquid)와 다른 앱 체인에 이러한 정의가 불공평해 보일 수 있지만, 이들은 나머지 암호화폐 시장과 고립되어 있으며, 주요 퍼블릭 블록체인에 이미 존재하는 대부분의 자산이 가진 네트워크 효과는 매우 강력합니다. 이더리움 L1 블록체인에서 하이퍼리퀴드 거래의 결과물과 상호작용하려면 먼저 자산을 브리징해야 하므로 상당한 지연 시간(잠재적으로 여러 블록)이 발생합니다. 특히, 하이퍼리퀴드와 다른 블록체인 간에는 실질적인 원자적 정산이 이루어지지 않습니다.

Hyperliquid는 애플리케이션이 시퀀싱을 완벽하게 제어할 수 있다면, 앱의 특정 사용 사례에 기반하여 신중한 결정을 내려야 한다는 것을 보여주었습니다. Atlas 팀도 "DeFi 전용 L2" 컨텍스트에서 내리는 결정에 대해 유사한 주장을 펼쳤습니다.

하지만 독립적인 블록체인을 구축하는 앱 블록체인은 이더리움 L2가 직면하는 것과 동일한 파편화 문제를 겪습니다. 이러한 파편화에 대응하여 일부 애플리케이션은 동일한 상태에 존재하는 다른 애플리케이션이 제공하는 원자적 구성 가능성을 활용하기 위해 이더리움이나 솔라나와 같은 범용 블록체인에 직접 구축하는 방식을 택할 것입니다. 이러한 애플리케이션은 합의 규칙을 제어할 수 없으며, 퍼블릭 블록체인 상의 스마트 계약 코드와 앱 구현에 필요한 프로토콜 외 인프라를 결합하여 구현해야 합니다. 다음 두 섹션에서는 이러한 애플리케이션에 대한 몇 가지 설계안을 살펴보고 이미 나타난 현상과의 유사점을 비교합니다.

(2.2) 범용 체인에서의 배치 처리

Cavey, Jakob, 그리고 Max는 현재 Solana에서 애플리케이션이 취소 우선순위를 구현할 수 있도록 하는 메커니즘으로 "비동기 메시지 큐"(AMQ)를 제안했습니다 . 이 메커니즘은 다음과 같이 작동합니다.

1. 블록 N에서는 비동기 트랜잭션이 큐에 추가되지만 실행되지는 않습니다. 이 큐는 스마트 계약의 상태로 유지되며 배치 역할을 합니다.
2. N+1 블록에서는 대기 중인 트랜잭션이 일괄 처리됩니다. "실행" 자체도 하나의 트랜잭션이며, 애플리케이션에서 지정한 우선순위에 따라 거래를 실행합니다.

아래 다이어그램은 이 과정을 두 블록에 걸쳐 보여줍니다.

upload_08c603422b911a7eed4b9f0ac5f4684a 1010×1356 86KB

취소 우선순위 지정을 위한 AMQ의 장점:

• 합의 메커니즘 변경 없음: L1 상태와 타임스탬핑을 사용하면 핵심 프로토콜을 변경하지 않고도 스마트 계약만으로 솔라나(또는 이더리움)에서 AMQ를 구현할 수 있습니다.

취소 우선순위 지정을 위한 AMQ의 단점:

• 거래 지연: 거래가 시작된 시점과 결제된 시점 사이에 최소 한 슬롯의 지연이 발생합니다. 취소 우선순위 지정으로 유동성과 실행 속도가 향상될 수 있지만, 거래 완료를 위해 추가 블록을 기다려야 하므로 사용자 경험(UX) 측면에서는 분명히 부정적인 영향을 미칩니다(슬롯 시간 때문에 이 문제는 솔라나보다 이더리움에서 더 심각할 수 있습니다). 두 가지 즉각적인 해결책이 있으며, 둘 다 합의 규칙 변경을 필요로 합니다. 첫째, 각 블록의 끝에서 일괄 처리되는 "예약 거래"를 허용하는 것입니다. 둘째, 계약이 블록 내에서 각 거래의 위치를 파악할 수 있도록 하는 것입니다. 이를 통해 계약은 마지막 거래 시점을 알고 그 직후 일괄 처리를 실행할 수 있습니다(이러한 "콜백" 메커니즘은 UniV4 훅 과 유사합니다).
• "다음 블록" 정산: 거래 지연으로 인해, 그리고 AMQ 게시물 에서 지적했듯이, 거래 실행의 비동기적 특성 때문에 동일 블록 내의 다른 솔라나 거래와의 원자적 정산이 불가능합니다. 블록 N에 더 이상 AMQ 거래가 없더라도(따라서 일괄 실행 결과가 확정적으로 알려져 있더라도), 거래 정산 은 블록 N+1에서 이루어지며, 따라서 블록 N의 어떤 거래도 해당 출력과 상호 작용할 수 없습니다(예: 플래시 대출 상환).
• 검열: 위에서 언급한 앱 체인 설계와 마찬가지로 AMQ 메커니즘의 신뢰성은 기본 체인의 검열 저항성에 크게 좌우됩니다. 솔라나 검증자는 블록 N에서 들어오는 모든 취소 요청을 간단히 검열하여 우선순위 큐를 무력화할 수 있습니다. 저자들은 이 점을 직접적으로 인정했습니다.

  "여러 제안자가 참여하지 않는 다른 모든 형태의 ACE와 마찬가지로, AMQ 역시 프로토콜에서 정한 틱 경계 내에서 검증자가 검열 및 지연을 통해 우회할 수 있습니다."
  – ACE 시행 .

AMQ는 ACE를 시행하기 위해 솔라나 검증자에 의존합니다. 일부 애플리케이션은 대신 오프체인 배치 솔루션을 선택하여 애플리케이션과 더욱 밀접하게 연관된 주체에게 신뢰를 이전할 수 있습니다.

(2.3) 오프체인 당사자에 의한 배치 처리

앱별 순서 지정 규칙을 구현하는 또 다른 방법은 오프체인 엔티티에 순서 지정 권한을 위임하는 것입니다. 소렐라(Sorella) 는 이더리움 기반의 하이브리드 온체인-오프체인 탈중앙화 거래소(DEX)를 구현했습니다. 소렐라의 설계는 별도의 합의 메커니즘을 활용하여 이더리움 L1에 보유된 유동성 포지션에 대해 실행할 트랜잭션 배치를 결정합니다.

참고 #1 : 유니스왑 용어에서 '캔슬(cancel)'은 '유동성 포지션 제거'를 의미합니다. 마찬가지로 '테이크(take)'는 단순히 '스왑'을 뜻합니다.

참고 #2 : 제안된 대로 Sorella는 취소 우선순위 기능을 구현하지 않고 있습니다. 대신 Top-of-Bundle 경매와 일괄 정산 거래에 집중하고 있습니다. 하지만 취소 우선순위 기능은 Sorella의 모델에서도 쉽게 구현할 수 있으므로, 이 예시를 통해 서로 다른 설계 방식 간의 연결고리를 설명하고자 합니다.

아래 다이어그램은 Sorella에서 취소 우선순위가 어떻게 변하는지 가상으로 보여줍니다.

upload_0b068c9d53c36619ed691c39cfeced44 946×1048 62.1 KB

취소 우선순위 지정을 위한 오프체인 배치 처리의 장점:

• 합의 메커니즘 변경 없음: AMQ와 마찬가지로 오프체인 배치 처리는 핵심 프로토콜을 수정하지 않고도 범용 L1 스토리지에서 완벽하게 구현할 수 있습니다.

취소 우선순위 지정을 위한 오프체인 배치 처리의 단점:

• 활성성: 소렐라는 이더리움과 별도의 합의 메커니즘에 의존하기 때문에 활성성 위험이 더 큽니다. 소렐라의 합의 과정이 중단되거나 악의적인 의도가 개입될 경우, 거래자와 유동성 공급자는 애플리케이션과 상호 작용할 수 없게 됩니다. 개발자들은 이 점을 구체적으로 언급하고 있습니다.

  "결과적으로 [ACE]는 필연적으로 추가적인 활성도 및 신뢰도 가정을 도입하는 외부 당사자를 포함하게 됩니다."
  – 활성 및 신뢰 가정 .

• 검열: 앱 체인과 온체인 배치 처리에 대한 검열 우려는 여전히 존재합니다. 특히, 순서 규칙은 소렐라 제안자가 기존 테이크를 선호하여 들어오는 취소 요청을 무시하는 것을 막을 수 없습니다. 반면, 소렐라 합의 참여자는 소렐라의 주요 이해관계자이므로, 검증자 인센티브는 일반적인 L1 검증자에 비해 프로젝트의 장기적인 성공과 더 밀접하게 연관되어 있다고 주장할 수 있습니다.
• "번들 후" 정산: 소렐라는 모든 소렐라 거래가 L1 풀에서 원자적으로 거래되는 원자 단위로 묶이기 때문에 이더리움 거래와 직접적으로 결합될 수 없습니다. 그러나 소렐라 번들이 블록에 포함되면 거래가 완전히 정산되고, 이후의 모든 거래(동일한 이더리움 블록 내에서도)는 그 결과로 생성된 상태를 활용할 수 있습니다.

참고 #3 : Sorella의 합의 메커니즘은 다른 트랜잭션 순서 지정 메커니즘으로 쉽게 대체될 수 있습니다. 예를 들어, BuilderNet은 TEE를 사용하여 검증 가능한 방식으로 블록 생성을 실행합니다. Sorella는 Sorella 합의 결과에서 서명된 번들 대신 위임된 TEE에서 서명된 번들만 허용하도록 수정할 수 있습니다. 이 모델에서도 활성성, 검열 및 정산 방식은 유사하며, 유일한 차이점은 TEE 보장과 비잔틴 합의 보장에서 발생하는 신뢰 가정에 있습니다.

(2.4) 프로토콜에 의해 강제되는 제안자 약속

바나베는 합의 의무의 진화, 특히 블록 생성 작업을 MEV-boost 경매로 아웃소싱하는 상황을 고려하여 프로토콜에 의해 강제되는 제안자 약속(PEPC)을 제안했습니다 . PEPC가 도입되면 제안자는 단순히 낙찰된 블록 생성자를 지정하는 것보다 더 일반적인 일련의 조치를 취할 것을 약속할 수 있습니다. 신뢰할 수 있는 제3자인 릴레이에 의존하는 MEV-boost와 달리, PEPC 약속은 이더리움 합의 메커니즘 자체에 의해 강제됩니다. 이러한 일반성은 이더리움에서 직접 취소 우선순위 기능을 구현하는 데에도 활용될 수 있습니다. 아래 다이어그램은 이를 보여줍니다.

upload_c00da71ed53662ee25a7f67ddb26097c 1090×1434 79.5KB

취소 우선순위 지정을 위한 PEPC의 장점:

• 추가적인 신뢰 가정은 필요 없습니다. PEPC가 구현될 경우, 제안자가 한 약속 이행은 이더리움의 합의 보장만큼 강력하게 강제될 것입니다.
• "네이티브" 정산: PEPC는 이더리움 트랜잭션의 나머지 부분과의 구성 가능성을 해치지 않으면서 취소가 실행보다 우선하도록 강제할 수 있을 만큼 충분히 표현력이 풍부합니다. 블록 생성 및 검증 프로세스는 더 복잡해지겠지만( 3.1절 에서 자세히 설명), 사용자 경험(UX) 관점에서 원자적 정산은 완전히 유지됩니다.

취소 우선순위 지정을 위한 PEPC의 단점:

• 콜드 스타트 문제: PEPC가 직면한 가장 큰 약점은 참여가 자발적이라는 점입니다. 사전 확인과 마찬가지로, PEPC에 의한 취소 우선 순위 부여는 실용화를 위해 상대적으로 많은 검증자 수를 필요로 합니다. 취소 우선 순위를 얻으려면, 해당 기능을 사용하기로 선택한 검증자만 계약 상태를 업데이트할 수 있습니다. 만약 이더리움 검증자의 1/10(이 또한 상당한 수치입니다!)만이 취소 우선 순위 부여에 참여한다면, 애플리케이션은 평균적으로 10블록에 한 번만 업데이트될 것이며, 이는 많은 거래 사용 사례에 있어 지나치게 느린 속도입니다.
• 합의 메커니즘 변경 필요: 이더리움 L1을 변경하여 블록 유효성 조건이 PEPC 커밋먼트에 따라 달라질 수 있도록 해야 합니다.

(3) 합의에 의해 강제되는 앱 지정 순서

PEPC는 앱 개발자와 검증자 간의 합의 도출을 위한 선택적 참여 방식의 시장이며, 콜드 스타트 문제에 직면해 있습니다. 상대적으로 연구가 덜 된 방향은 검증자의 참여를 의무화하는 것입니다. 이는 이상적인 시나리오처럼 보입니다. 분산된 검증자 집합이 유동성과 경제 활동을 위한 셸링 포인트 역할을 하는 범용 L1 거래소로서, 앱 개발자는 초기 설정 없이도 거래 순서를 제어할 수 있습니다. 하지만 이것이 과연 실현 가능할까요?

대부분의 경우 답은 '예'이지만, 세부 사항은 예상외로 미묘합니다. 이 글의 나머지 부분에서는 Hyperliquid가 주문 체결보다 취소 요청을 우선시할 수 있도록 이더리움 합의 알고리즘을 가장 간단하게 변경하는 방법을 살펴보겠습니다. 여기서 제안한 해결책보다 설계 공간이 훨씬 더 다양하며, 제대로 탐구하기 위해서는 추가적인 연구가 필요하다는 점을 강조하고 싶습니다.

각 계약이 블록 단위로 기능 실행 순서를 지정할 수 있도록 스마트 계약 언어를 간단히 수정하는 것을 생각해 보겠습니다. 예를 들어, 취소 우선순위 지정을 다음과 같이 인코딩할 수 있습니다.

 DEX contract func Take ; func Cancel ; order = [Cancel, Take]

이제 블록 내에서 DEX 컨트랙트의 두 함수 중 하나를 호출하는 트랜잭션은 블록이 유효하려면 순서를 준수해야 합니다. 아래 그림은 두 개의 컨트랙트, 네 개의 트랜잭션, 그리고 하나의 블록을 보여주는 예시입니다.

upload_6293557cdc347eb3614eef9185df2c63-1 1038×1526 105KB

이 그림에 대한 몇 가지 참고 사항:

• 계약은 DEX와 Oracle 두 가지가 있으며, 각각 두 가지 기능을 수행합니다.
• DEX의 경우, 블록 내에서 취소는 획득보다 먼저 이루어져야 합니다.
• 오라클의 경우, 블록 내에서 모든 업데이트 작업은 모든 읽기 작업보다 먼저 수행되어야 합니다.
• DEX 및 오라클 컨트랙트에 대한 다양한 함수 호출을 포함하는 트랜잭션이 네 개 있습니다.
• 마지막 블록에는 [TX2, TX1, TX3] 시퀀스가 포함되어 있으며, 함수 호출 순서는 [DEX::Cancel, DEX::Take, Oracle::Update, DEX::Take] 입니다.
• 최종 주문은 두 계약의 현지 주문 규칙을 모두 준수합니다.
• TX3 와 TX4 는 상호 배타적입니다. 왜냐하면 [TX3, TX4] 와 [TX4, TX3] 순서 모두 계약 순서 규칙 중 하나를 위반하기 때문입니다. 이에 대한 자세한 내용은 섹션 3.1을 참조하십시오.

스마트 계약 언어를 변경하고 합의 과정에서 이를 강제함으로써 애플리케이션에 이러한 유형의 제어 권한을 부여하지 못할 근본적인 이유는 없습니다(Hyperliquid가 취소 우선순위 지정을 통해 실제로 구현한 방식이 바로 이것입니다). 여러 면에서, 프로토콜 내에서 ACE를 구현하는 것은 앞서 설명한 네 가지 대안보다 더 깔끔한 해결책입니다(예: 제안자가 애플리케이션이 지정한 순서 제약 조건을 준수 해야 하는 PEPC와 유사합니다). 특히, 네이티브 정산 기능을 제공하고, 추가적인 신뢰 가정 없이 L1 합의와 동일한 보장을 제공하며, 검증자 참여를 요구함으로써 콜드 스타트 문제를 해결합니다.

하지만 몇 가지 분명한 단점이 있습니다. 특히 L1 블록체인에서의 블록 생성 복잡성 제한(이는 이더리움의 명시적인 목표 중 하나임)과 동일 블록체인 내 애플리케이션의 구성 가능성(스마트 계약 플랫폼의 핵심 특징)을 고려할 때 더욱 그렇습니다. 다음 하위 섹션에서는 이러한 문제점들을 구체적인 예시와 함께 자세히 살펴보겠습니다.

(3.1) 블록 구성 복잡성

계약에서 순서 제약 조건을 지정할 수 있도록 허용하면 유효한 블록을 생성하는 복잡성이 증가합니다. 이를 설명하기 위해 현재 이더리움의 블록 생성 과정을 살펴보는 것이 유용합니다. 대부분의 블록은 정교한 블록 생성자가 PBS(Public Behavior System)를 통해 생성하지만, 약 8%의 블록은 여전히 제안자가 직접 생성합니다( mevboost.pics 참조). 우선순위 수수료를 최대화하는 블록을 가스 한도 내에 생성하는 것은 NP-완전 문제(0/1 배낭 문제)이지만, 대부분의 블록은 최대 용량보다 훨씬 작으며, 유효하고 기본 수수료를 지불하는 모든 트랜잭션을 멤풀에 포함하는 것만으로도 일반적으로 가능합니다. 멤풀에 있는 트랜잭션 수가 블록 가스 한도보다 많을 경우, 우선순위 수수료를 기준으로 탐욕 알고리즘을 실행하면 복잡한 방식 없이 블록을 생성하려는 사용자에게 좋은 휴리스틱을 제공합니다. 일부 트랜잭션이 되돌려지더라도 블록에 포함되는 것은 여전히 유효하며, 되돌려지기 전까지 처리하는 데 필요한 단위당 가스비를 지불합니다. 지역 건설업자는 블록이 가득 찰 때까지 가장 높은 팁을 주는 거래를 계속 추가할 수 있으며, 결과적으로 생성된 블록이 유효하고 팁 수익이 최적 수익의 최소 절반 이상임을 확신할 수 있습니다.

만약 스마트 계약이 (위에서 언급한 것처럼) 블록별 순서 지정 규칙을 지정할 수 있도록 허용한다면, 대기 중인 거래 목록이 주어졌을 때 (합리적인 수수료 수익을 가진) 유효한 블록 하나를 찾는 것조차 복잡해질 수 있습니다. 다음 예시는 이를 보여줍니다. 두 가지 거래 유형을 고려하고 유니스왑V2 스타일의 함수 이름을 사용합니다.

1. SWAP은 풀에 있는 한 자산을 다른 자산과 교환하는 것입니다("인수").
2. REMOVE는 특정 가격(즉, "취소")으로 유동성 풀에서 유동성을 인출합니다.

우리는 스마트 컨트랙트에서 각 블록 내에서 REMOVE 호출이 SWAP 호출보다 먼저 실행되도록 명시했습니다(취소 우선순위). 예시에서 REMOVE와 SWAP 모두 가격의 패리티를 변경할 수 있습니다. REMOVE의 경우, LP가 풀에서 특정 토큰을 제거하여 가격을 변경할 수 있습니다. SWAP의 경우, 스왑 규모에 따라 가격의 패리티가 변경되거나 유지됩니다.

세 가지 가상의 거래를 생각해 보겠습니다. 이 거래들의 동작은 거래 실행 시작 시점의 풀 가격의 패리티에 따라 달라지며, 괄호 안의 내용은 해당 작업이 가격 패리티에 미치는 영향을 나타냅니다.

모든 트랜잭션은 패리티에 따라 REMOVE 또는 SWAP 중 하나가 될 수 있습니다. 후보 블록 [TX1, TX2, TX3] 을 생각해 보겠습니다. 풀이 짝수 상태로 시작할 때 어떤 일이 발생하는지 살펴보겠습니다.

1. TX1이 먼저 실행되어 SWAP을 수행하고 가격의 패리티를 홀수로 바꿉니다.
2. TX2는 풀 가격이 홀수임을 감지하고 REMOVE를 실행하려고 시도합니다.

이미 문제가 발생했습니다! 저희의 순서 지정 규칙에 따르면 REMOVE는 SWAP보다 먼저 실행되어야 하므로 [TX1, TX2, TX3] 유효한 실행 순서가 아닙니다. 실제로 모든 3! = 6 가지 거래 순서 조합 중에서 TX3으로 시작하는 두 가지만 유효합니다. 아래 목록은 각 후보의 순서와 그에 따른 함수 호출을 보여줍니다. 풀 가격의 패리티는 처음부터 동일하다는 점을 기억하세요.

• 123 : 1 (홀수 교환) → 2 (홀수 제거) → 3 (홀수 교환)
  • 결과: SWAP, REMOVE, SWAP => 유효하지 않음
• 132 : 1 (홀수 교환) → 3 (홀수 교환) → 2 (홀수 제거)
  • 결과: SWAP, SWAP, REMOVE => 유효하지 않음
• 213 : 2 (교환: 홀수) → 1 (제거: 홀수) → 3 (교환: 홀수)
  • 결과: SWAP, REMOVE, SWAP => 유효하지 않음
• 231 : 2 (교환: 홀수) → 3 (교환: 홀수) → 1 (제거: 홀수)
  • 결과: SWAP, SWAP, REMOVE => 유효하지 않음
• 312 : 3 (홀수 제거) → 1 (홀수 제거) → 2 (홀수 제거)
  • 결과: 제거, 제거, 제거 => 유효함
• 321 : 3 (홀수 제거) → 2 (홀수 제거) → 1 (홀수 제거)
  • 결과: 제거, 제거, 제거 => 유효함

물론 블록 시작 시 풀 가격이 홀수일 수도 있습니다. 이 경우 [TX3, TX2, TX1] 과 [TX3, TX1, TX2] 는 모두 유효하지 않은 순서가 되며, 유효한 순서는 [TX1, TX2, TX3] 과 [TX2, TX1, TX3] 뿐입니다.

간단한 예시와 세 건의 거래만으로도 유효한 순서를 찾기 위해 수많은 경우의 수를 확인해야 했습니다. 거래 건수, 함수, 제약 조건이 많아질수록 유효한 순서를 찾는 문제는 조합론적으로 훨씬 더 복잡해집니다.

(3.2) 구성 가능성

블록 생성의 복잡성 외에도, ACE는 스마트 계약과 트랜잭션이 동일한 블록체인에서 실행될 때 일반적으로 누리는 구성 가능성을 약화시킵니다. 두 개의 DEX(A와 B)가 각각 위에서 설명한 것과 같은 순서 규칙(REMOVE가 SWAP보다 먼저 실행되어야 함)을 가지고 있다고 가정해 보겠습니다.

• 모든 REMOVE(A)는 모든 SWAP(A)보다 먼저 수행되어야 합니다.
• 모든 REMOVE(B)는 모든 SWAP(B)보다 먼저 수행되어야 합니다.

이제 멤풀에서 다음과 같은 두 가지 트랜잭션이 발생한다고 상상해 보세요.

• TX1: 제거(A) + 교환(B)
• TX2: 제거(B) + 교환(A)

이러한 기준이 다소 임의적으로 보일 수 있지만, 오프체인 가격이 크게 변동한 경우를 생각해 보세요. 앨리스는 풀 A에, 밥은 풀 B에 유동성 공급자(LP) 포지션을 보유하고 있습니다. 앨리스와 밥은 모두 가격이 정체된 자신의 풀에서 유동성을 빼내려고 하며, 빼낸 LP 토큰을 사용하여 다른 풀의 정체된 가격과 교환하려고 합니다.

결과적으로 발생하는 거래는 함께 포함될 수 없다는 점에 유의하십시오. 어느 하나라도 다른 하나보다 먼저 발생하면 각 DEX에 적용되는 두 가지 순서 규칙 중 하나를 위반하게 됩니다. 물론 앨리스와 밥은 각자의 REMOVE 거래와 해당 SWAP 거래를 분리할 수 있지만, 그렇게 하면 각 거래의 원자성이 유지되지 않으며, 자신의 풀에서 유동성을 인출하지 않는 한 다른 풀에서 SWAP을 실행하는 데 필요한 자본이 부족할 수 있습니다.

또 다른 예로, 오라클과 DEX에 대한 다음 정렬 규칙을 살펴보겠습니다.

• Oracle: UPDATE 문은 READ 문보다 먼저 실행되어야 합니다.
• DEX: REMOVE는 SWAP보다 먼저 실행되어야 합니다.

Oracle은 모든 읽기 작업이 최신 데이터에 접근할 수 있도록 보장하고자 하며, DEX는 취소 우선순위 규칙을 계속 사용합니다. 이제 다음 두 트랜잭션을 살펴보겠습니다.

• TX1: 업데이트(오라클) + 스왑(덱스)
• TX2: 읽기(오라클) + 제거(덱스)

다시 말해, 두 거래 모두 자연스럽게 발생할 수 있습니다. 첫 번째 경우, 사용자가 오라클에서 가격을 업데이트한 후 원자적으로 스왑을 수행합니다. 두 번째 경우, LP 포지션을 제거하기 전에 오라클 가격을 읽습니다. 그러나 두 거래는 동일한 블록에 포함될 수 없습니다. 그렇게 하면 두 계약 중 하나에서 순서 위반이 발생하기 때문입니다. 물론, 이러한 작업들을 개별 거래로 분리하여 순서를 재정렬할 수도 있지만, 이렇게 하면 두 애플리케이션 간의 구성 가능성이 무너지게 됩니다.

블록 생성의 복잡성은 순서 지정 규칙이 다르고 여러 컨트랙트와 상호 작용하는 수많은 트랜잭션이 있을 경우 더욱 증가합니다. 다음 예시에서는 각 트랜잭션이 오라클 컨트랙트를 한 번, DEX 컨트랙트를 한 번 호출합니다.

다시 한번, [TX1, TX2, TX3] 순서를 시도해 보겠습니다. 이 순서는 Oracle과 DEX의 순서 규칙 모두를 위반하므로 분명히 작동하지 않습니다. 여기서 유효한 트랜잭션 집합을 생성하는 유일한 순서는 [TX3, TX2, TX1] 입니다. 아래 각 항목은 하나의 가능한 순서 조합을 보여줍니다.

• 123 : 1 (읽기, 교환) → 2 (읽기, 제거) → 3 (업데이트, 제거 )
  • (READ가 UPDATE보다 먼저 실행됨) 및 (SWAP이 REMOVE보다 먼저 실행됨) => 유효하지 않음
• 132 : 1 (읽기, 교환) → 3 (업데이트, 삭제) → 2 (읽기, 삭제)
  • (READ가 UPDATE보다 먼저 실행됨) 및 (SWAP이 REMOVE보다 먼저 실행됨) => 유효하지 않음
• 213 : 2 (읽기, 삭제) → 1 (읽기, 교환) → 3 (업데이트, 삭제 )
  • (READ가 UPDATE보다 먼저 실행됨) 및 (SWAP이 REMOVE보다 먼저 실행됨) => 유효하지 않음
• 231 : 2 (읽기, 삭제) → 3 (업데이트, 삭제) → 1 (읽기, 교환)
  • (READ가 UPDATE보다 먼저 실행됨) => 잘못된 동작
• 312 : 3 (업데이트, 제거) → 1 (읽기, 교환) → 2 (읽기, 제거 )
  • (SWAP이 REMOVE 앞에 옴) => 유효하지 않음
• 321 : 3 (업데이트, 삭제) → 2 (읽기, 삭제) → 1 ( 읽기 , 스왑) => 유효함

어떤 면에서 이 예제의 블록 생성 문제는 이전 예제의 풀 패리티 런타임 검사보다 해결하기 쉽습니다. 트랜잭션을 실행하기 전에 함수 순서를 확인할 수 있기 때문입니다. 그러나 세 트랜잭션 모두에 대한 유효한 순서를 찾는 데에는 우선순위 수수료를 기준으로 하는 단순한 탐욕적 순서 지정보다 훨씬 더 많은 계산이 필요할 수 있다는 점은 변함이 없습니다. 또한, 트랜잭션이 DEX 또는 오라클 계약에서 호출하는 함수가 풀 가격 및/또는 오라클의 가격 피드에 따라 달라지고, 이러한 요소들이 런타임 중에 변경되는 더욱 복잡한 예제를 쉽게 구성할 수 있습니다.

(3.3) 가능한 적응 및 완화 방안

이전 섹션에서 우리는 ACE를 범용 L1 검증 시스템에 통합하는 것이 합의 메커니즘을 약간 수정하는 대신 블록 생성 복잡성을 증가시키는 대가를 치르면 가능하다는 것을 살펴보았습니다. 블록 생성 복잡성 증가는 여러 단점을 수반합니다. 우선, 로컬 빌더(외부 블록 생성을 맡기지 않고 직접 블록을 생성하는, 전문성이 부족한 검증자)가 최적의 거래 수수료 수익을 정확하게 예측하기 어렵게 만들어 중앙 집중화될 수 있습니다. 또한, 어쩌면 더 중요한 단점은 사용자, 지갑, 프런트엔드가 거래 순서 지정의 복잡성 증가를 고려하여 거래 수수료 로직과 호출하는 함수들을 조정해야 한다는 점입니다.

예를 들어, 거래 포함 시점에 대한 선호도가 높은 사용자(예: 오래된 견적이 선택되는 것을 막기 위해 긴급하게 취소하려는 사용자)는 거래 로직을 최대한 단순하게 만들어 빌더가 정적 분석을 쉽게 수행할 수 있도록 할 수 있습니다. 이를 통해 빌더는 블록 내 다른 위치에서 거래를 다시 실행하지 않고도 거래 동작을 사전에 더 잘 예측할 수 있습니다. 그러나 이러한 단순성 추구는 제약이 따르고 구성 가능성을 저해할 수 있습니다. 거래가 복잡해지고 더 많은 계약과 상호 작용할수록 빌더는 거래가 어떤 함수와 계약에 영향을 미칠지 정적으로 예측하는 데 대한 확신도가 떨어집니다. 충분히 복잡한 거래는 동작이 변경될 가능성이 매우 높아 빌더가 해당 거래를 제외하거나(또는 복잡한 거래를 포함함으로써 다른 많은 거래를 제외할 수도 있음) 할 수 있습니다. 따라서 이는 거래의 표현력과 예상 포함 시간 사이의 절충점을 제시합니다. ACE 순서로 실행되는 계약과 상호 작용 하지 않는 거래조차도 상호 작용하는 거래와 블록 공간을 공유하므로, 실행 전에 거래의 정확한 동작을 알리는 완벽하게 신뢰할 수 있는 방법이 없기 때문에 이러한 절충점을 고려해야 합니다.

위에서 언급한 내용 중 상당수는 형식적인 정의가 아님을 유의하십시오. 예를 들어, 표현력에 따른 활성도 저하 정도를 정확하게 정량화하지는 않았습니다. 또한, 트랜잭션 복잡성이 증가함에 따라 빌더의 신뢰도가 어떻게 영향을 받는지도 모델링하지 않았습니다. 이 두 가지 모두 추가 연구가 필요한 흥미로운 방향입니다. 예를 들어, 전자는 다양한 블록 생성 알고리즘의 근사 보장을 명시적으로 모델링해야 하고, 후자는 EVM/SVM에 대한 정적/동적 분석에 대한 도메인 지식이 필요합니다. 본 연구의 목표는 이러한 흥미로운 상충 관계를 정성적으로 제시하고, 도메인 전문가들에게 이러한 질문들이 탐구할 가치가 있는 흥미로운 문제임을 설득하는 것입니다.

명시적 신호

블록 생성자에게 전체 트랜잭션 순서 분석을 맡기는 대신, 프로토콜은 트랜잭션에 메타데이터를 추가하여 트랜잭션이 호출할 함수를 미리 명시적으로 증명하도록 함으로써 보다 명확한 신호 전달을 지원하거나 요구할 수 있습니다. 이더리움에서 이러한 트랜잭션 사전 확정은 현재 차기 하드 포크에 포함될지 여부가 검토 중인 블록 접근 목록(Block-Access Lists) 과 유사합니다. 솔라나에서는 트랜잭션이 이미 계정 주소 에 커밋되지만, 두 경우 모두 함수 수준의 메타데이터를 추가하는 것은 블록 생성자가 트랜잭션을 직접 실행하지 않고도 순서 지정 프로세스를 시작할 수 있도록 하는 데 매우 중요합니다.

이러한 구조에서는 트랜잭션이 함수 시그니처를 정확하게 선언한 경우에만 유효한 것으로 간주되며, 선언되지 않은 함수를 호출하는 경우 트랜잭션은 취소되지만 가스 비용은 지불됩니다. 이 메커니즘은 블록 생성자가 가스 비용을 확실히 받을 수 있도록 보장하고, 트랜잭션이 활성 상태에 영향을 미치지 않고도 임의로 복잡해질 수 있도록 합니다. 물론 이러한 변화는 분석 부담을 트랜잭션 생성자에게 전가합니다. 지갑과 프런트엔드가 함수 호출을 지정할 수 있어야 한다는 것은 직관적으로 타당해 보이지만, 트랜잭션이 어떤 함수를 호출할지 사전에 알 수 없는 상태 의존적인 상황이 발생할 수 있습니다(예: 온체인 라우팅 트랜잭션은 최적의 가격을 찾기 위해 각 DEX를 탐색할 때 스왑 함수를 호출하도록 미리 확정할 필요가 없습니다). 다시 말해, 실행 계층 전문가가 아닌 관점에서 볼 때, 이러한 설계 공간은 풍부하고 잠재적으로 유망해 보입니다.

ACE에서 블록 생성의 복잡성이 블록 검증의 복잡성을 훨씬 능가한다는 점도 주목할 만합니다. 블록을 검증할 때(예: 검증자가 투표 방식을 결정할 때), 영향을 받은 계약 목록과 트랜잭션 순서를 런타임에 동적으로 확인할 수 있으며, 계약에서 정한 순서 규칙을 위반하는 경우 블록 검증 복잡성을 크게 증가시키지 않고도 상태 전환 함수가 즉시 무효를 반환하도록 할 수 있습니다.

(4) 결론

이 글에서는 취소 우선순위라는 관점에서 ACE의 다양한 설계 후보들을 살펴봅니다. 각 설계는 위에서 언급한 바와 같이 여러 가지 장단점을 가지고 있습니다. 또한, 계약이 단일 블록 내에서 반드시 준수되어야 하는 함수 실행 순서를 지정할 수 있는 기본적인 형태로 ACE를 L1에 구현하는 방안도 검토합니다. 구현 가능한 순서 규칙의 설계 공간은 매우 넓으며, 탐구해 볼 가치가 있습니다. 예를 들어, 탈중앙화 거래소(DEX)의 가격 변동이 너무 급격할 경우 작동하는 더욱 표현력이 풍부한 순서 규칙을 생각해 볼 수 있습니다. 나아가, 순서 규칙은 단순히 계약 내 함수 실행 순서를 지정하는 것보다 훨씬 더 복잡할 수 있습니다.

ACE는 블록에 추가적인 유효성 제약 조건을 부과하는 프로토콜의 한 예입니다. 이러한 제약 조건은 함수 호출 순서를 지정하는 애플리케이션 개발자로부터 도출됩니다. Hyperliquid는 이러한 종류의 제약 조건이 최종 사용자, 특히 거래를 중심으로 구축된 앱 체인 환경에서 유용할 수 있음을 보여주었습니다. 이 아이디어는 프로토콜 설계의 더 넓은 영역을 제시하는 것으로 보이며, 주요 질문은 다음과 같습니다.

1. 실현 가능성: 범용 블록체인이 (복잡성을 과도하게 증가시키지 않고) 적용 할 수 있는 제약 조건은 무엇인가?
2. 바람직성: 최종 사용자 또는 생태계 전반의 복지에 도움이 되는 제약 조건은 무엇인가?

이는 " 탈중앙화가 사용자에게 미치는 경제적 영향 분석 "과 유사한 맥락으로, 프로토콜이 공급 제약을 준수할 때 최종 사용자 가격에 어떤 영향을 미치는지 분석합니다. 우리는 이러한 연구를 프로토콜이 준수할 수 있는 애플리케이션별 제약 조건으로 확장하는 데 가치가 있다고 생각합니다.

이 글이 취소 우선순위 지정 예시를 통해 서로 다른 ACE 메커니즘을 통합하고, 블록 생성의 복잡성과 구성 가능성 문제를 보여주는 구체적인 예시를 통해 ACE의 미묘한 부분들을 명확히 하며, 이더리움 환경에서 ACE를 블록에 내장하는 것의 잠재력을 탐구하는 데 도움이 되었기를 바랍니다. 우리는 이것이 앞으로도 지속적인 연구와 탐구가 필요한 강력한 아이디어라고 생각합니다.