저자: 유키 유미나가 출처: 소렐라 번역: 샨 오우바, 진써차이징(Jinse)
소개
최대 클레임 가치(MEV)를 푸는 것은 이더 의 오랜 과제였습니다. 가치 공급망은 중재자들이 다양한 전략을 통해 빈번한 활동에 참여하도록 장려하는데, 이는 종종 개인 투자자 사용자를 희생시키는 결과를 낳습니다. 많은 연구자들이 프로토콜 수준의 변경을 통해 MEV 문제를 해결하려고 시도했지만, 이러한 노력은 아직 만족스러운 해결책을 제공하지 못했습니다. 현재의 인프라와 경매 메커니즘은 블록 단위로 MEV를 효과적으로 포착할 수 있지만 포착된 가치를 공평하게 분배하지 않습니다. MEV의 가치가 각 애플리케이션 자체에서 보다 효율적으로 포착되고 내재화되는 대신 네트워크 검증자에게 속해야 하는 이유가 무엇일까요?
그래서 ASS(Application Specific 순서)가 등장했습니다. ASS는 프로토콜 수준에서 규칙을 다시 작성하려고 하지 않고 개별 애플리케이션이 자체 트랜잭션을 순서 방법을 제어할 수 있도록 합니다. 이를 통해 ASS는 온체인 애플리케이션이 MEV의 부정적 영향으로부터 사용자와 유동성을 보호할 수 있도록 하는 동시에, 이더 이더 흘러갈 가치를 포착할 수 있는 기회를 제공합니다.
상상해보세요. 고빈도 거래자 각 사용자의 중재를 극대화하기 위해 경쟁하는 대신(거의 모든 중재 가치가 검증자와 기반 체인으로 유출됨), 각 애플리케이션은 자체 거래 순서 규칙을 정의하여 사용자를 위해 보다 맞춤화되고 효율적이며 공정한 시스템을 만들 수 있습니다. 이는 네트워크 계층에서 MEV를 해결하려는 것에서 가장 중요한 애플리케이션 계층에서 MEV를 해결하려는 것으로의 전환을 의미합니다.
배경
ASS(Application Specific 순서) 개념은 Matheus가 DEX(탈중앙화 거래소)의 VSR(Verifiable 순서 Rules)에 관해 수행한 연구에서 유래되었습니다. Matheus는 VSR이 채굴자의 거래 순서 에 대한 영향을 줄임으로써 거래 실행을 개선하고 MEV를 완화할 수 있음을 입증했습니다. 그런 다음 Tarun은 이 아이디어를 확장하여 독점적인 순서 규칙을 적용하는 것이 사용자, 검증자, 순서 와 같은 프로토콜 참여자의 보상 기능에 어떻게 상당한 영향을 미칠 수 있는지 보여주었습니다.
여기서 보상 함수는 특정 거래 순서 의 경제적 가치를 나타냅니다. 이 값은 프로토콜 참여자가 순서 에서 얻는 이익이나 유용성을 반영하며, 순서 재무적 결과에 어떤 영향을 미치는지 보여줍니다. 보상 기능에는 두 가지 주요 특징이 있습니다.
평활화되지 않은 수익률 : 순서 약간만 변해도 MEV가 크게 변동할 수 있습니다.
비단조적 수익률 : 순서 의 작은 변화로 인해 MEV가 증가하거나 감소할 수 있지만, 변화의 방향은 일관되지 않습니다.
보상 함수가 이 두 가지 특성을 모두 가지고 있을 때, 순서 전략을 최적화하는 것은 매우 복잡해집니다. 이 경우 사용자에게 공정한 결과를 제공하고 DeFi 생태계를 지속 가능하게 하기 위해 애플리케이션 계층에서 보다 정교하고 맞춤화된 접근 방식이 필요합니다.
앱별 순서 어떻게 작동하나요?
ASS를 이해하려면 먼저 기존 거래 공급망을 검토해야 합니다.
기존 시스템에서는:
거래는 공개 또는 비공개 메모풀로 전송됩니다.
빌더는 이러한 거래를 수집하여 블록으로 묶습니다.
빌더들은 블록 경매에서 경쟁하고, 우승자의 블록은 블록체인에 포함되고, 입찰가의 가치는 블록 제안자에게 지불됩니다.
이와 대조적으로 ASS 기반 애플리케이션은 다음과 같은 특징을 갖고 있습니다.
제한된 순서 권한 : 이 제한은 지정된 순서 또는 스테이킹 검증자만 애플리케이션의 계약과 상호 작용할 수 있도록 보장하여 애플리케이션의 내부 가치 분배 논리를 악의적으로 우회하는 것을 방지합니다.
애플리케이션별 메모리 풀 : 사용자는 공개 메모리 풀에 거래를 제출하는 대신 애플리케이션별 메모리 풀에 의도를 보냅니다. 이러한 의도는 애플리케이션별 순서 에 의해 수집되어 처리됩니다.
주문 독립 결과 : 순서 규칙을 시행하고 타겟 사용자에게 최상의 경제적 수익을 제공하기 위해 ASS 거래는 빌더의 다른 거래 순서 과 독립적이어야 합니다. 이는 애플리케이션의 상태가 합의 메커니즘에 의해 제어되도록 보장함으로써 달성됩니다. ASS 주문은 하나의 묶음으로 통합되어 건설업체에 전송되어 포함됩니다. 번들은 다른 애플리케이션에서 접근하는 상태와 충돌하지 않으므로 블록 내에서의 위치는 중요하지 않습니다.
ASS는 이러한 기본 원칙을 통해 온체인 모든 애플리케이션이 실행 및 계약 상태에 대한 주권을 회복하고, 이를 통해 주권적 애플리케이션을 실현할 수 있도록 합니다.
실제 사례: 옹스트롬
주권적 응용 프로그램의 실제적 사례로서, Angstrom은 UniswapV4에 대한 후크로, 중앙화 거래소(CEX) 및 탈중앙화 거래소(DEX)의 중재자가 미치는 부정적인 영향으로부터 유동성 공급자를 보호하는 데 사용되며, 동시에 거래자"메자닌 공격"으로부터 보호합니다. Angstrom 노드 네트워크는 이더 과 병렬로 작동하여 실행할 거래 집합에 대한 합의에 도달합니다. 과정은 다음과 같습니다.
CEX-DEX 중재자들은 AMM(거래 수수료 없음)을 통해 최초로 거래할 권리를 얻기 위해 입찰합니다.
동시에 사용자는 예약된 스왑 작업을 서명된 제한 주문 형태로 Angstrom의 메모리 풀로 보냅니다.
Angstrom 네트워크는 합의 프로토콜을 실행하고 첫 번째 스왑이 가장 높은 입찰을 하는 중재자 거래인 번들을 형성합니다. 입찰 금액은 거래소 내 유동성 공급자에 비례하여 분배됩니다. 다른 모든 유효한 지정가 주문과 AMM 유동성은 동일한 통합 청산 가격으로 실행됩니다.
그런 다음 번들은 제안된 Angstrom 노드에 의해 이더 의 빌더와 공개 메모풀로 전송됩니다.
생명성과 신뢰 가정
ASS는 본질적으로 주권적 애플리케이션이 규정된 순서 규칙에 따라 탈중앙화 순서 권한을 위임하는 부분적 블록 구성의 한 형태입니다. 그러므로 ASS에는 필연적으로 추가적인 활력과 신뢰 가정을 도입하는 외부 당사자가 관여하게 됩니다.
활동 가설
주권 애플리케이션은 프로토콜을 올바르게 따르고 시기적절한 상태 업데이트를 제공하기 위해 애플리케이션별 순서 에 의존합니다. 활성 상태 위반(예: 네트워크 분할)이 발생하면 유효한 합의가 복원될 때까지 사용자는 애플리케이션의 일부와 상호 작용하지 못할 수 있습니다.
주권적 애플리케이션은 업데이트가 순서 에 따라 달라지는 계약 상태의 범위를 제한할 수도 있습니다. 이를 통해 계약의 외부 종속성을 최소화할 수 있으므로 순서 오류가 발생하더라도 중요 상태(예: 예치된 유동성)에 계속 액세스할 수 있습니다.
신뢰 가정
순서 규칙이 정렬 순서 에게 준수되도록 하기 위해 주권 기반 애플리케이션은 암호 경제 솔루션(PoS 등)이나 암호화 방법(TEE 또는 MPC 등)을 활용할 수 있습니다. 구체적인 접근 방식은 애플리케이션의 요구 사항에 따라 크게 다를 수 있습니다. 실행 최적화에 대한 합의가 필요한 경우도 있고, 암호화 메커니즘을 통해 실행 전에 개인 정보 보호를 보장하는 데 중점을 두는 경우도 있습니다. 순서 의 신뢰 오버헤드를 줄이고 각 주권 애플리케이션의 고유한 목표를 충족시키는 데 사용할 수 있는 도구가 많이 있습니다.
검열 저항
이더 생태계에는 여러 유형의 검열이 있습니다.
규제 검토: 건설업체 및 중계업체는 OFAC 제재 목록에 따라 거래를 검토합니다. 이는 현재 이더 에서 가장 두드러진 검열 형태 중 하나이며, 주로 릴레이어가 수행합니다.
경제적 검열: 동기가 있는 공격자는 차단 제안자에게 뇌물을 주어 피해자의 거래를 검열하게 할 수 있습니다.
노드 수준 검열: P2P 네트워크의 노드는 수신 거래 전파를 거부할 수 있습니다. 대부분의 노드가 유입 거래에 대해 동일한 의견을 가지고 있다는 가정 하에 프로토콜이 최적으로 작동한다면 이는 큰 문제가 될 수 있습니다. 더욱이 이러한 프로토콜에서는 적대자가 정직한 노드의 로컬 뷰를 분할(슬롯 끝에 있는 노드의 절반에만 거래를 보냄)하려는 인센티브를 받을 수 있으며, 결국 프로토콜을 중단시킬 수 있습니다.
많은 연구자들은 이더 에 더 나은 검열 저항성이 필요하다고 말했습니다. 다중 동시 제안자(MCP) 및 포크 선택 필수 포함 목록(FOCIL)과 같은 일부 제안이 표면화되어 지속적인 논의의 초점이 되었습니다.
검열 저항성 역시 주권 적용에 있어서 주요 문제입니다. 애플리케이션별 순서 추가적인 개인 거래 및 주문 흐름을 수신하는 데 다양한 이해관계를 가진 외부 엔터티일 수 있습니다. 예를 들어, MM (Market Making) 역할을 하는 애플리케이션별 검증자는 경쟁하는 MM (Market Making) 가 보낸 거래를 검열할 인센티브를 갖습니다. 따라서 기본 프로토콜이 검열되지 않더라도 그 위에 있는 주권적 애플리케이션은 지역 검열의 대상이 될 수 있습니다.
ASS 검열 저항 메커니즘의 예로는 옹스트롬이 있습니다. 모든 유효한 주문이 다가올 기간에 포함되도록 하기 위해 Angstrom 노드는 모든 검증된 수신 주문을 브로드캐스트하고 제안된 거래 패키지에 포함하는 것에 대한 합의에 도달해야 합니다. 거래 패키지에 네트워크 대다수가 관찰한 순서가 없으면 제안자는 처벌을 받게 됩니다. 아래는 앵스트롬의 검열 저항 메커니즘에 대한 그림입니다.
구성 가능성의 딜레마
주권 애플리케이션이 직면한 주요 과제 중 하나는 외부 계약 상태와 상호 작용하는 거래의 구성성을 보장하는 것입니다. 애플리케이션별 거래를 임의의 외부 거래와 단순히 묶는 것은 주권적 애플리케이션과 사용자를 보호하는 데 필요한 순서 독립적 성격을 훼손합니다. 단일의 잘못된 비 ASS 트랜잭션이 애플리케이션별 트랜잭션과 결합되는 경우 전체 번들을 복구하는 2차 효과가 발생할 수 있습니다. 이런 일이 발생하면 주권적 애플리케이션은 할당된 기간 내에 사용자의 명령을 실행할 수 없게 되며(유효한 합의에 도달했음에도 불구하고) 사용자 경험과 전반적인 복지에 해를 끼칩니다.
그럼에도 불구하고, 구성성 문제에는 잠재적인 해결책이 존재하며, 다양한 팀이 그 중 여러 가지를 탐구하고 있습니다. 이러한 계획에는 사전 확인, 공유된 애플리케이션별 순서, 빌더 약정과 같은 개념이 포함되어 있으며, 각각은 구성 가능성의 정도와 신뢰 오버헤드 간의 균형을 제공합니다.
사전 확인을 통합합니다
사전 확인의 포함을 설명하려면 먼저 사전 확인이 어떻게 작동하는지 이해하는 것이 필요합니다. 현재 시대의 특정 기간 전에 특정 거래 집합에 포함되도록 제안자가 스테이킹 를 제시했는지 확인하기 위해 사전 확인에 기반한 암호경제적 보안을 활용합니다. 이 보장은 참여 제안자가 게시한 보증금 크기에 따라 제한됩니다.
포함 사전 확인은 거래 포함이 어떠한 계약 상태와도 무관한 사전 확인의 특수한 형태입니다. 사전 확인에 포함되도록 요청된 거래는 상태와 무관하고 분쟁성이 없어야 합니다. 즉, 해당 거래의 실행은 블록 내의 위치에 영향을 받지 않아야 합니다. 포함 사전 확인을 활용함으로써 제안자는 ASS 번들이 동일한 블록에 포함된 경우에만 ASS가 아닌 거래를 포함하기로 약속할 수 있습니다. 이러한 접근 방식은 비분쟁성 거래와 ASS 번들 간에 암호경제적으로 강화된 구성성을 제공합니다.
그러나 이 솔루션이 제공하는 제한적인 구성성을 고려하면 추가적인 복잡성과 신뢰 오버헤드가 특정 주권 애플리케이션에 대한 이점을 능가할 수 있습니다. 그러므로 단순성과 기능성 사이에서 보다 효과적인 균형을 제공하는 대체 접근 방식을 모색하는 것이 중요합니다.
애플리케이션별 순서 및 제조업체 약속 공유
주권 애플리케이션은 제안자의 약속에 의존하지 않고도 애플리케이션별 순서 사용하여 여러 애플리케이션에서 거래 순서 관리할 수 있습니다. 예를 들어, 여러 개의 주권적 애플리케이션에 대한 거래를 처리하는 순서 각 애플리케이션의 순서 규칙을 따르는 한 이들 간의 원자적 구성을 용이하게 할 수 있습니다. 이 공유 애플리케이션별 순서 접근 방식은 주권 애플리케이션 전반에 걸쳐 원활한 구성 및 조정을 가능하게 합니다.
그러나 주권이 없는 애플리케이션의 경우 다른 솔루션이 필요합니다. 주권 애플리케이션 순서 에 참여하는 블록 빌더의 거래 포함 약속은 비주권 애플리케이션과 주권 애플리케이션 간에 원자적 구성성을 생성할 수 있습니다. 빌더는 두 가지 유형의 애플리케이션 간에 지정된 거래 순서를 보장합니다. 이러한 빌더 약속은 ASS의 구성성 격차를 메울 수 있습니다.
주권 및 비주권 dApp 간 원자적 구성성을 위한 빌더 커밋먼트(오른쪽) 및 주권 애플리케이션 간 원자적 구성성을 위한 공유 애플리케이션별 순서(왼쪽)의 그림
빌더 약속의 경제적 역학, 사전 확인을 통합하는 가능성, 잠재적인 2차 효과에 대한 의문이 여전히 남아 있지만, ASS의 구성성 문제는 시간이 지나면서 해결될 것이라고 믿습니다. Astria와 Primev와 같은 팀은 공유 순서 및 빌더 약속에 대한 개선된 프레임 적극적으로 연구하고 개발하고 있습니다. 이러한 발전이 진행됨에 따라 구성 가능성은 더 이상 주권 응용 프로그램의 문제가 되지 않을 것입니다.
애플리케이션별 L2 및 L1을 갖춘 ASS
현재, dApp은 거래 순서 제어하기 위해 애플리케이션별 체인을 구축해야 합니다. 프로토콜 소유 빌더(PoB)와 같은 개념을 통해 Cosmos L1은 더욱 표현적인 순서 규칙을 갖고 MEV를 수집하여 해당 애플리케이션에 재배포하는 데 도움이 됩니다. 마찬가지로, VSR이 있는 L2 순서 도 이러한 작업을 수행할 수 있습니다. 두 솔루션 모두 애플리케이션에서 MEV를 더욱 표현력 있게 순서 하고 캡처할 수 있게 해주지만, ASS는 다음과 같은 특징 때문에 독특합니다.
거래 실행에는 신뢰 오버헤드가 없습니다. ASS는 순서 거래를 실행하거나 결제하지 않습니다. 순서 만 위임됩니다. 기준 신뢰 가정은 이더 이나 다른 L2와 같은 기본 실행 환경에서 확장됩니다.
브릿지가 필요 없이 유동성과 주문 흐름에 접근하세요. dApp은 체인의 트래픽과 유동성을 직접 활용할 수 있습니다.
자산은 기본 실행 환경에 남아 있으며 동결 수 없습니다. L2와 달리 대부분의 ASS는 사용자가 브리지 계약으로 자금을 잠그도록 요구하지 않습니다. 이러한 설계 선택은 더 나은 보안을 제공합니다. 애플리케이션별 순서 실패하더라도 순서 스마트 계약에서 설정한 경계 내에서만 거래를 제어할 수 있으므로 잠재적인 피해가 제한됩니다. 일부 L2 솔루션은 안전 기능(비상구 및 강제 격리 등)을 구현하지만 이러한 조치를 실제로 사용하기 어려운 경우가 많습니다. L2 업데이트 연결이 끊어진 후 사용자는 비상 종료를 활성화하기까지 며칠을 기다려야 할 수도 있습니다. 마찬가지로, L1을 통한 의무적 포함에는 보통 적어도 하루의 지연이 필요합니다. 아마도 가장 중요한 점은, 이러한 보안 조치는 대부분 사용자에게 없는 기술적 전문 지식을 필요로 하기 때문에 평균적인 사람에게는 실용적이지 않다는 것입니다.
강력한 ASS 활성도 가정 - L2 활성도는 순서 기반으로 하지 않는 한 실행 노드(일반적으로 롤업 순서 )에 따라 달라집니다. L1의 활성 여부는 노드의 정직한 대다수가 해당 상태 전환 함수를 다시 실행하는 데 달려 있습니다. 주권형 애플리케이션의 활성 여부는 주로 기본 실행 환경에 따라 달라지며, 스마트 계약은 애플리케이션별 순서 에 의존해야 하는 부분을 지정할 수 있습니다.
주권 응용 프로그램, L2, L2 기반 및 L1의 비교 차트
결론적으로
ASS를 사용하면 애플리케이션이 트랜잭션 순서 완벽하게 제어할 수 있어 실행의 복잡성을 관리하지 않고도 사용자 정의 규칙을 정의할 수 있습니다. 이러한 제어를 통해 애플리케이션은 실행을 제어하여 사용자에게 최적의 결과를 제공할 수 있습니다. 예를 들어, 앵스트롬에서는 LP와 교환자가 1등급 참여자로 취급되어 맞춤형 순서 규칙을 통해 경제적 수익을 직접적으로 향상시킵니다.
또한 ASS는 다양한 암호경제학 및 암호화 도구를 활용하여 사용자 지불의 최적화를 강화하고 강력한 검열 저항 메커니즘을 구현할 수 있습니다. 스테이킹 이나 슬래싱과 같은 암호경제적 솔루션은 순서 사이에 정직한 행동을 장려할 수 있으며, TEE나 MPC와 같은 암호화 방법은 개인 정보 보호와 보안을 강화할 수 있습니다. ASS는 이러한 도구를 사용하여 보다 안전하고 효율적이며 사용자 중심적이고 주권적인 애플리케이션을 만들도록 설계될 수 있는 엄청난 잠재력을 가지고 있습니다.
ASS가 많은 기회를 제공하더라도 기본적으로 구성이 불가능하다는 등의 과제는 여전히 남아 있습니다. 그러나 사전 확인, 공유 ASS, 빌더 약속을 포함한 솔루션은 이러한 장벽을 극복하기 위한 유망한 접근 방식을 제공합니다. 아직 몇 가지 문제가 남아 있지만, 우리는 이러한 접근 방식을 개선하여 더 원활하고 구성 가능한 ASS 환경을 제공하기 위해 노력하고 있습니다.
우리의 목표는 ASS를 하나씩 진행하면서 DeFi를 더욱 지속 가능하게 만드는 것입니다.
