지속 가능한 DeFi를 위한 애플리케이션별 시퀀싱(ASS)의 이해

저자: 유미나가 유키 출처: 소렐라 번역: 굿오바, 골드파이낸스

소개

최대 추출 가능한 가치(MEV)를 해결하는 것은 항상 이더리움의 과제였습니다. 가치 공급망은 다양한 전략을 통해 차익거래자들의 빈번한 활동을 유도하며, 이는 종종 소매 사용자들에게 손해를 끼칩니다. 많은 연구자들이 프로토콜 레이어 변경을 통해 MEV를 해결하려고 시도했지만, 아직 만족할 만한 해결책을 제시하지 못하고 있습니다. 현재의 인프라와 경매 메커니즘은 블록에서 MEV를 포착하는 데는 효과적이지만, 포착된 가치를 공정하게 분배하지 못합니다. 왜 MEV의 가치가 각 애플리케이션 자체에서 더 효과적으로 포착되고 내재화되지 않고 네트워크 검증자에게 돌아가야 하는 것일까요?

그리하여 애플리케이션별 시퀀싱(ASS)이 탄생했습니다. ASS는 프로토콜 계층에서 규칙을 다시 작성하는 대신 개별 애플리케이션이 트랜잭션 주문 방식을 제어할 수 있도록 합니다. 이를 통해 온체인 앱은 MEV의 부정적인 영향으로부터 사용자와 유동성을 보호하는 동시에, 이더 검증자에게 흘러갈 수 있는 가치를 확보할 수 있는 기회를 얻을 수 있습니다.

배경

애플리케이션별 정렬(ASS)의 개념은 탈중앙화 거래소(DEX)의 검증 가능한 정렬 규칙(VSR)에 관한 마테우스의 연구에서 비롯되었습니다. 마테우스는 다음과 같은 사실을 증명했습니다. VSR은 거래 주문에 대한 채굴자의 영향을 줄임으로써 거래 체결을 개선하고 MEV를 완화할 수 있으며, 이후 타룬은 애플리케이션별 주문 규칙이 사용자, 검증자, 주문자와 같은 프로토콜 참여자의 보상 기능에 어떻게 큰 영향을 미칠 수 있는지 보여줌으로써 이 아이디어를 확장했습니다.

여기서 보상 함수는 특정 트랜잭션 주문의 경제적 가치를 나타냅니다. 이 값은 계약 참여자가 거래 순서를 통해 얻는 이익 또는 효용을 반영하며, 순서가 재무 결과에 어떤 영향을 미치는지 보여줍니다. 페이오프 함수에는 두 가지 주요 특징이 있습니다.

• 비평활화된 페이오프: 시퀀싱의 작은 변화는 MEV에 큰 변동을 일으킬 수 있습니다.

• 비단조 수익률: 시퀀싱의 작은 변화는 MEV를 증가 또는 감소시킬 수 있지만 같은 방향이 아닐 수 있습니다.

성과 보상 함수에 이러한 두 가지 특성이 모두 있는 경우 순위 전략 최적화는 매우 복잡해집니다. 이 경우, 사용자에게 공정한 결과를 제공하고 지속 가능한 탈중앙 금융 생태계를 보장하기 위해 애플리케이션 레이어에서 보다 복잡하고 맞춤화된 접근 방식이 필요합니다.

앱별 정렬은 어떻게 작동하나요?

ASS를 이해하려면 먼저 기존 트랜잭션 공급망을 살펴볼 필요가 있습니다.

기존 시스템에서는:

• 거래가 퍼블릭 또는 프라이빗 메모리 풀(멤풀)로 전송됩니다.

• 빌더는 이러한 트랜잭션을 수집하여 블록으로 패키징합니다.

• 빌더들은 블록 경매를 위해 경쟁하고, 승자의 블록은 블록체인에 포함되며, 입찰가는 해당 블록의 제안자에게 지급됩니다.

반면, ASS 기반 애플리케이션은 다음과 같은 특징이 있습니다:

• < strong>주문 권한 제한: 이 제한은 지정된 주문자 또는 서약 확인자만 앱의 컨트랙트와 상호작용할 수 있도록 하여 앱의 내부 가치 할당 로직을 악의적으로 우회하는 것을 방지합니다.

• 앱 전용 메모리 풀: 사용자가 트랜잭션을 공개 메모리 풀에 제출하는 대신 앱 전용 메모리 풀에 인텐트를 전송합니다. 그러면 이러한 인텐트는 앱 전용 시퀀서에 의해 수집되고 처리됩니다.

• 주문에 구애받지 않는 결과: 주문 규칙을 적용하고 대상 사용자에게 최상의 재정적 수익을 제공하려면 ASS 트랜잭션이 빌더의 다른 트랜잭션 주문과 독립적이어야 합니다. 이는 애플리케이션의 상태가 합의 메커니즘에 의해 제어되도록 함으로써 달성할 수 있으며, ASS 주문은 번들로 통합되어 빌더에게 전송되어 포함됩니다. 번들은 다른 애플리케이션이 액세스하는 상태와 충돌하지 않으므로 블록에서 번들의 위치는 상관없습니다.

이러한 기본 원칙을 통해 ASS는 모든 온체인 애플리케이션이 실행 및 컨트랙트 상태에 대한 주권을 되찾을 수 있게 함으로써 소버린 애플리케이션을 가능하게 합니다.

실제 사례: 앵스트롬

주권 적용의 실제 사례로는 앵스트롬이 가장 먼저 있습니다. 실제 사례로, 앵스트롬은 유동성 공급자를 중앙화된 거래소(CEX) 및 탈중앙화된 거래소(DEX) 차익거래자로부터 보호하고 트레이더를 "메자닌 공격"으로부터 보호하기 위한 유니스왑V4의 후크입니다. 앵스트롬 노드 네트워크는 이더와 병렬로 작동하여 실행할 거래 세트에 대한 합의를 도출합니다. 프로세스는 다음과 같습니다:

• CEX-DEX 차익거래자는 AMM을 통해 가장 먼저 교환할 수 있는 권리를 입찰합니다(수수료 없음).

• 동시에 사용자는 예약된 스왑 작업을 서명된 지정가 주문의 형태로 앵스트롬의 메모리 풀에 전송합니다.

• 앵스트롬 네트워크는 합의 프로토콜을 실행하고 첫 번째 스왑이 최고 입찰 차익거래가 되는 번들을 형성합니다. 입찰 금액은 스왑 내 기초 유동성 공급자에게 비례 배분됩니다. 다른 모든 유효한 지정가 주문과 AMM에 대한 유동성은 동일한 균일 청산 가격으로 체결됩니다.

• 번들은 제안하는 앵스트롬 노드에 의해 이더와 공용 메모리 풀의 빌더로 전송됩니다.

활동 및 신뢰 가정

ASS의 중심에는 부분 블록이 있습니다. 소버린 애플리케이션이 정해진 정렬 규칙에 따라 분산된 운영자 네트워크에 정렬 권한을 위임하는 형태로 구성됩니다. 따라서 ASS에는 필연적으로 추가 활동과 신뢰 가정을 도입하는 외부 당사자가 포함됩니다.

활동 가정

소버린 애플리케이션은 애플리케이션별 시퀀서에 의존하여 프로토콜을 올바르게 따르고 적시에 상태 업데이트를 제공합니다. 활동 중단(예: 네트워크 파티셔닝)이 발생하는 경우 사용자는 유효한 합의가 복구될 때까지 애플리케이션의 특정 부분과 상호 작용하지 못할 수 있습니다.

소버린 앱은 시퀀서에 따라 업데이트되는 컨트랙트 상태의 범위를 제한할 수도 있습니다. 이렇게 하면 컨트랙트의 외부 의존성을 최소화하여 시퀀서 장애가 발생하더라도 예치된 유동성과 같은 중요한 상태에 계속 액세스할 수 있습니다.

신뢰 가정

시퀀서가 규정된 시퀀싱 규칙을 준수하도록 하기 위해 소버린 앱은 암호 경제 솔루션(예: 지분 증명) 또는 암호화 방법(예: TEE 또는 MPC)을 활용할 수 있습니다. 특정 방법은 애플리케이션의 필요에 따라 크게 달라질 수 있으며, 실행 최적화에 대한 합의가 필요한 경우도 있고, 암호화 메커니즘을 통해 실행 전 프라이버시를 보장하는 데 중점을 두는 경우도 있습니다. 시퀀서의 신뢰 오버헤드를 줄이고 각 소버린 애플리케이션의 고유한 목표를 달성하는 데 사용할 수 있는 여러 가지 도구가 있습니다.

검열에 저항하기

이더리움 생태계에는 여러 유형의 검열이 존재합니다:

1. 규제 감시: 빌더와 릴레이는 OFAC 제재 목록에 따라 거래를 면밀히 조사합니다. 이는 현재 이더리움에서 가장 두드러진 형태의 검토 중 하나이며, 주로 중계자가 수행합니다.

2. 경제적 검열: 동기가 있는 공격자는 블록 제안자를 매수하여 피해 거래를 검열할 수 있습니다.

3. 노드 수준 검열: P2P 네트워크의 노드는 들어오는 트랜잭션의 전파를 거부할 수 있습니다. 이는 대부분의 노드가 수신 트랜잭션을 동일하게 본다는 가정 하에 프로토콜이 최적으로 작동하는 경우 큰 문제가 될 수 있습니다. 또한 이러한 프로토콜에서 공격자는 정직한 노드의 로컬 뷰를 분할하여(시간 슬롯이 끝날 때 절반의 노드에게만 트랜잭션을 전송함으로써) 결과적으로 프로토콜을 중단시키려는 유인을 가질 수 있습니다.

많은 연구자들이 이더를 위한 더 나은 검열 방지 메커니즘의 필요성을 제기해 왔습니다. 다중 동시 제안자(MCP) 및 포크 옵션 강제 포함 목록(FOCIL)과 같은 여러 제안이 등장했으며, 지속적인 논의의 초점이 되고 있습니다.

검토 저항도 소버린 애플리케이션의 주요 관심사입니다. 앱별 시퀀서는 추가적인 비공개 거래와 주문 흐름을 받는 데 다양한 이해관계를 가진 외부 기관일 수 있습니다. 예를 들어, 시장 조성자 역할을 하는 애플리케이션 특정 검증자는 경쟁 시장 조성자가 전송한 거래를 검토할 인센티브가 있습니다. 결과적으로 최상위 소버린 애플리케이션은 기본 프로토콜이 아니더라도 로컬 조사를 받을 수 있습니다.

검열 저항 메커니즘의 예로 앙스트롬을 들 수 있습니다. 모든 유효한 주문이 예정된 시간 슬롯에 포함되도록 하기 위해 앙스트롬 노드는 검증된 모든 수신 주문을 브로드캐스트하고 제안된 거래 패키지에 포함되는지 합의에 도달해야 합니다. 네트워크 대다수가 관찰한 주문이 거래 패키지에 누락되면 제안자는 페널티를 받게 됩니다. 다음은 앵스트롬 검토 보이콧 메커니즘에 대한 설명입니다.

구성성 딜레마

소버린 앱이 직면한 주요 과제 하나는 외부 컨트랙트 상태와 상호작용하는 트랜잭션의 컴포저빌리티를 보장하는 것입니다. 애플리케이션별 트랜잭션을 임의의 외부 트랜잭션과 단순히 번들링하면 소버린 애플리케이션과 사용자를 보호하는 데 필요한 순서 불가지론이 약화됩니다. 하나의 유효하지 않은 비ASS 트랜잭션이 애플리케이션별 트랜잭션과 결합되면, 전체 번들을 복원하는 2차 효과가 발생할 수 있습니다. 이 경우 소버린 앱은 유효한 합의에도 불구하고 할당된 시간 내에 사용자의 주문을 실행할 수 없게 되어 사용자 경험과 전반적인 안녕에 해를 끼칠 수 있습니다.

그러나 컴포저빌리티 문제에 대한 잠재적인 해결책이 있으며, 여러 팀에서 몇 가지 해결책을 모색하고 있습니다. 여기에는 사전 확인, 공유 애플리케이션별 시퀀서, 빌더 약속을 통합하는 개념이 포함되며, 각 개념은 컴포저빌리티의 정도와 신뢰의 오버헤드 사이에서 절충점을 제공합니다.

사전 승인 포함

사전 승인 포함을 설명하려면 먼저 사전 승인 기반이 어떻게 작동하는지 이해하는 것이 중요합니다. 사전 승인 기반은 암호화폐 경제적 보안을 활용하여 제안자가 현재 기간 내 특정 기간까지 특정 거래 집합의 포함을 보장하기 위해 담보를 제공했는지 확인합니다. 이 보증은 참여 제안자가 게시한 증거금 규모에 따라 제한됩니다.

포함 사전 확정은 거래의 포함 여부가 계약 상태와 무관한 특별한 형태의 사전 확약 기반입니다. 포함 사전 확인을 요청하는 트랜잭션은 상태 독립적이고 경합이 없어야 하며, 이는 블록 내 위치에 따라 체결이 영향을 받지 않음을 의미합니다. 포함 사전 확인을 활용하면 제안자는 ASS 번들이 동일한 블록에 포함된 경우에만 비ASS 트랜잭션의 포함을 약속할 수 있습니다. 이 접근 방식은 경합이 없는 트랜잭션과 ASS 번들 간에 암호화 경제적으로 강제된 구성성을 제공합니다.

그러나 이 솔루션이 제공하는 제한된 구성 가능성을 고려하면 일부 소버린 애플리케이션의 경우 추가된 복잡성과 신뢰 오버헤드가 이점을 능가할 수 있습니다. 따라서 단순성과 기능 간에 보다 효과적인 균형을 제공하는 대안을 모색하는 것이 중요합니다.

앱별 시퀀서 및 메이커 커밋 공유

소버린 앱은 앱별 시퀀서를 사용해 제안자 커밋에 의존하지 않고 여러 앱에서 트랜잭션의 시퀀싱을 관리할 수 있습니다. 예를 들어, 여러 소버린 애플리케이션의 트랜잭션을 처리하는 시퀀서는 각 애플리케이션의 시퀀싱 규칙을 따르는 한 애플리케이션 간의 원자적 컴포저빌리티를 촉진할 수 있습니다. 이러한 공유 애플리케이션별 시퀀서 접근 방식은 소버린 애플리케이션 간에 원활한 컴포저빌리티와 조정을 가능하게 합니다.

그러나 비소버린 앱의 경우, 다른 솔루션이 필요합니다. 소버린 앱의 시퀀싱과 관련된 블록 빌더의 트랜잭션 포함 약속은 비소버린 앱과 소버린 앱 간의 원자적 구성 가능성을 만들 수 있습니다. 빌더는 두 가지 유형의 애플리케이션 간에 지정된 트랜잭션 순서를 보장합니다. 이 빌더 커미티는 ASS 컴포저빌리티 격차를 해소합니다.

소버린과 비소버린 디앱 간의 아토믹 컴포저빌리티를 위한 빌더 커밋 그림(오른쪽) 및 소버린 애플리케이션 간의 아토믹 컴포저빌리티 공유 그림. 애플리케이션별 시퀀서 그림(왼쪽)

빌더 커밋의 경제적 역학, 사전 확인 통합의 실현 가능성, 잠재적인 2차 효과에 대한 의문이 남아 있지만, 시간이 지나면 ASS의 구성 가능성 문제가 해결될 것으로 확신합니다.Astria와 Primev. Astria 및 Primev와 같은 팀은 공유 시퀀싱 및 빌더 커밋을 위한 개선된 프레임워크를 적극적으로 연구 및 개발하고 있습니다. 이러한 발전이 진행됨에 따라 컴포저빌리티는 더 이상 소버린 앱에서 문제가 되지 않을 것입니다.

앱별 L2와 L1이 있는 아카이브

현재 디앱은 트랜잭션 순서를 제어하기 위해 앱별 체인을 구축해야 합니다. 프로토콜 소유 빌더(PoB)와 같은 개념은 코스모스 L1이 MEV를 캡처하고 이를 애플리케이션에 재분배하는 데 도움이 되는 보다 표현적인 순서 규칙을 가질 수 있도록 합니다. 마찬가지로 VSR이 있는 L2 시퀀서도 이러한 작업을 수행할 수 있습니다. 두 솔루션 모두 애플리케이션에서 MEV를 보다 표현적으로 정렬하고 캡처할 수 있지만, ASS는 다음과 같은 기능으로 인해 고유합니다.

1. 트랜잭션 실행에 신뢰 오버헤드가 발생하지 않음 - ASS는 정렬된 트랜잭션을 실행하거나 정산하지 않습니다. 시퀀싱만 위임됩니다. 기본 신뢰는 기본 실행 환경(예: 이더넷 또는 기타 L2)에서 확장되는 것으로 가정합니다.

2. 유동성 및 주문 흐름에 대한 접근 - 사용자는 브리징할 필요가 없습니다. dApp은 체인의 흐름과 유동성을 직접 활용할 수 있습니다.

3. 자산은 기본 실행 환경에 유지되며 동결될 수 없음 - L2와 달리 대부분의 ASS는 사용자가 자금을 브리징된 컨트랙트에 고정할 필요가 없습니다. 이러한 설계 선택은 더 나은 보안을 제공합니다. 애플리케이션별 시퀀서가 실패하더라도 시퀀서는 스마트 컨트랙트가 설정한 경계 내에서만 트랜잭션을 제어할 수 있기 때문에 잠재적 피해가 제한됩니다. 일부 L2 솔루션은 보안 기능(예: 비상구 및 필수 포함)을 구현하지만, 이러한 조치는 실제로 사용하기 어려운 경우가 많습니다. L2 업데이트에 연결이 끊긴 후 사용자는 비상구가 활성화될 때까지 며칠을 기다려야 할 수도 있습니다. 마찬가지로 L1을 통한 강제 포함은 일반적으로 최소 하루 이상 지연이 필요합니다. 가장 중요한 것은 이러한 보안 조치는 일반적으로 대부분의 사용자가 보유하지 못한 기술적 전문 지식이 필요하기 때문에 일반 사용자에게는 비현실적이라는 점입니다.

4. Strong-ASS 활동 가정 - L2의 활동은 실행 노드(일반적으로 롤업 시퀀서)에 따라 달라집니다. L1의 활동은 정직한 대다수의 노드에 따라 달라집니다. 해당 상태 전환 함수를 다시 실행합니다. 소버린 애플리케이션의 활동은 주로 기본 실행 환경에 따라 달라지며, 스마트 컨트랙트는 애플리케이션별 시퀀서에 의존해야 하는 부분을 지정할 수 있습니다.

소버린 애플리케이션, L2, L2 및 L1 기반 비교 표

결론

ASS는 애플리케이션이 트랜잭션 순서를 완벽하게 제어하여 구현의 복잡성을 관리할 필요 없이 사용자 정의 규칙을 정의할 수 있게 해줍니다. 이러한 제어를 통해 애플리케이션은 실행을 제어하여 사용자에게 최적화된 결과를 제공할 수 있습니다. 예를 들어, 앵스트롬에서는 LP와 거래소가 동급 최고의 참여자로 취급되어 맞춤형 정렬 규칙을 통해 재무 수익을 직접적으로 개선합니다.

또한, ASS는 다양한 암호화 경제 및 암호화 도구를 활용하여 사용자 결제의 최적화를 강제하고 강력한 검열 보이콧을 구현할 수 있습니다. 서약 및 할인과 같은 암호화 경제 솔루션은 시퀀서들 사이에서 정직한 행동을 장려할 수 있으며, TEE 및 MPC와 같은 암호화 방법은 개인 정보 보호와 보안을 강화할 수 있습니다. 이러한 도구를 통해 ASS의 설계 잠재력은 엄청나며, 보다 안전하고 효율적이며 사용자 중심의 소버린 애플리케이션을 만들 수 있습니다.

ASS는 많은 기회를 제공하지만 네이티브 컴포저빌리티 부족과 같은 과제도 남아 있습니다. 하지만 사전 검증, 공유 ASS, 빌더 커밋을 포함하는 솔루션은 이러한 장애물을 극복할 수 있는 유망한 방법을 제공합니다. 일부 문제가 남아 있지만, 더 원활하고 컴포저블한 ASS 환경을 제공하기 위해 이러한 접근 방식을 개선하기 위해 최선을 다하고 있습니다.

우리의 목표는 한 번에 한 가지씩, 더 지속 가능한 DeFi를 만드는 것입니다.