SevenX Ventures: Uniswap V4 이후, 협처리기의 응용 공간은 얼마나 될까?

저자: Hill

최근 Uniswap v4가 출시되었습니다. 기능이 아직 완전하지 않지만, 우리는 커뮤니티가 전례 없는 가능성을 폭넓게 탐색하기를 바랍니다. DeFi 분야에서 Uniswap v4의 엄청난 영향력을 소개하는 많은 글이 있을 것으로 예상되므로, 본 문서에서는 Uniswap v4가 새로운 블록체인 인프라인 협처리기(Coprocessor)를 어떻게 촉발하는지에 대해 논의하겠습니다.

Uniswap v4 소개

백서에 명시된 바와 같이, Uniswap v4는 주로 4가지 개선 사항이 있습니다:

• 훅(Hook): 훅은 외부 배포형 계약으로, 풀 실행 중 특정 지점에서 개발자가 정의한 논리를 실행합니다. 이러한 훅을 통해 통합자는 유연하고 사용자 정의 가능한 실행이 가능한 집중 유동성 풀을 생성할 수 있습니다.

• 싱글톤(Singleton): Uniswap v4는 모든 풀이 단일 계약에 의해 관리되는 싱글톤 디자인 패턴을 채택하여 풀 배포 비용을 99% 절감했습니다.

• 플래시 회계(Flash Accounting): 각 작업은 내부 순 잔액, 즉 증분을 업데이트하며, 잠금이 종료될 때만 외부 이체가 이루어집니다. 플래시 회계는 원자 교환 및 추가와 같은 복잡한 풀 작업을 간소화합니다.

• 네이티브 ETH: WETH 및 ETH 거래 쌍을 지원합니다.

절감된 대부분의 가스 비용은 마지막 3가지 개선 사항 덕분이지만, 의심할 여지 없이 가장 흥미로운 새로운 기능은 본문 시작 부분에서 언급한 새로운 하이라이트인 훅입니다.

훅은 유동성 풀을 더욱 복잡하고 강력하게 만듭니다

Uniswap v4의 주요 향상 기능은 훅이 열어주는 프로그래머블성에 중점을 두고 있습니다. 이 기능은 유동성 풀을 더욱 복잡하고 강력하게 만들어, 그 어느 때보다 더 유연하고 사용자 정의 가능하게 합니다. Uniswap v3의 집중 유동성(Uniswap v2의 순 업그레이드)과 비교할 때, Uniswap v4의 훅은 유동성 풀의 운영 방식에 대해 더 광범위한 가능성을 제공합니다.

이 버전은 Uniswap v3의 순 업그레이드로 볼 수 있지만, 실제 구현에서는 그렇지 않을 수 있습니다. Uniswap v2 풀과 비교할 때, Uniswap v3 풀은 항상 업그레이드로 간주됩니다. 왜냐하면 Uniswap v3에서 수행할 수 있는 "최악의" 업그레이드는 유동성을 전체 가격 범위에 "집중"시키는 것이며, 이는 Uniswap v2와 동일한 방식으로 작동하기 때문입니다. 그러나 Uniswap v4에서는 유동성 풀의 프로그래머블성이 거래 또는 유동성 제공 경험을 개선하지 않을 수 있으며, 오류가 발생할 수 있고 새로운 공격 매개체가 나타날 수 있습니다. 유동성 풀의 운영 방식이 여러 가지로 변화했기 때문에, 훅 특성을 활용하려는 개발자는 신중해야 합니다. 그들은 설계 선택이 풀 기능에 미치는 영향과 유동성 제공자의 잠재적 위험을 철저히 이해해야 합니다.

Uniswap v4에 도입된 훅은 블록체인에서 코드가 실행되는 방식에 중대한 변화를 의미합니다. 전통적으로 블록체인 코드는 미리 정해진 순서로 실행됩니다. 그러나 훅은 특정 코드가 다른 코드보다 먼저 실행되도록 더 유연한 실행 순서를 허용합니다. 이 기능은 복잡한 계산을 스택의 가장자리에 밀어내고, 단일 스택에서 해결하는 것이 아니라는 점에서 차별화됩니다.

본질적으로 훅은 Uniswap의 네이티브 계약 외부에서 더 복잡한 계산을 지원합니다. Uniswap v2와 Uniswap v3에서는 Uniswap 외부에서 수동 계산을 통해 다른 스마트 계약과 같은 외부 트리거를 통해 이 기능을 구현할 수 있었지만, Uniswap v4는 훅을 유동성 풀의 스마트 계약에 직접 통합했습니다. 이전의 수동 프로세스와 비교할 때, 이러한 통합은 프로세스를 더 투명하고 검증 가능하며 신뢰할 필요가 없게 만듭니다.

훅이 가져오는 또 다른 이점은 확장성입니다. Uniswap은 이제 새로운 스마트 계약(유동성 마이그레이션이 필요함)이나 포크에 의존할 필요가 없습니다. 훅은 이제 새로운 기능을 직접 구현할 수 있게 하여, 오래된 유동성 풀을 새롭게 변화시킵니다.

Uniswap v4 유동성 풀의 오늘은 다른 dApp의 내일입니다

내 예상으로는, 점점 더 많은 dApp이 Uniswap v4처럼 계산을 자신의 스마트 계약 외부로 밀어낼 것입니다.

Uniswap v4의 현재 운영 방식은 유동성 풀 실행을 임의의 조건을 삽입하고 Uniswap v4 계약 외부의 계산을 트리거할 수 있도록 허용합니다. 지금까지 유일하게 유사한 경우는 플래시 론으로, 동일한 블록 내에서 대출을 상환하지 않으면 실행이 복구됩니다. 단지 계산은 여전히 플래시 론 계약 내에서 발생합니다.

Uniswap v4의 설계는 Uniswap v3에서 구현할 수 없거나 효과가 좋지 않았던 많은 이점을 가져왔습니다. 예를 들어, 이제 내장형 오라클을 사용할 수 있어, 잠재적 공격 매개체를 자주 도입하는 외부 오라클에 대한 의존도를 줄일 수 있습니다. 이러한 내장형 설계는 가격 정보의 안전성과 신뢰성을 강화하며, 이는 DeFi 프로토콜이 운영될 수 있는 핵심 요소입니다.

또한, 이전에는 외부에서 트리거해야 했던 자동화가 이제 유동성 풀에 직접 내장될 수 있습니다. 이러한 통합은 보안 문제를 완화할 뿐만 아니라 외부 트리거와 관련된 신뢰성 문제를 해결합니다. 또한 유동성 풀이 더 원활하고 효율적으로 운영될 수 있도록 하여, 전체 성능과 사용자 경험을 향상시킵니다.

마지막으로, Uniswap v4에 도입된 훅을 통해 유동성 풀 내에서 더 다양한 보안 기능을 직접 구현할 수 있습니다. 과거에 유동성 풀이 채택한 보안 조치는 주로 감사, 취약점 보상 및 보험 구매였습니다. Uniswap v4 덕분에 개발자는 이제 풀의 스마트 계약 내에서 다양한 실패 안전 메커니즘과 낮은 유동성 경고를 설계하고 구현할 수 있습니다. 이러한 발전은 풀의 보안을 강화할 뿐만 아니라 유동성 제공자에게 더 높은 투명성과 통제력을 제공합니다.

전통적인 휴대폰과 비교할 때, 스마트폰의 장점은 프로그래머블성에 있습니다. 스마트 계약은 오랫동안 "지속 스크립트"의 그림자 속에서 살아왔습니다. 이제 Uniswap v4의 이점을 통해 유동성 풀 스마트 계약은 새로운 프로그래머블 업그레이드를 통해 "더 똑똑해졌습니다". 나는 이해할 수 없습니다. 노키아에서 아이폰으로 업그레이드할 기회가 있다면, 왜 모든 dApp이 이 방향으로 업그레이드하고 싶지 않을까요? 노키아가 아이폰보다 더 신뢰할 수 있기 때문에 일부 스마트 계약이 현 상태를 유지하고 싶어하는 것은 이해하지만, 내가 말하는 것은 dApp의 미래 발전 방향입니다.

dApp은 자신의 "훅"을 사용하고 싶어하며, 이는 확장성 문제를 야기합니다

모든 다른 dApp에 이를 적용한다고 상상해 보십시오. 우리는 그 안에 트리거할 조건을 삽입하고, 원래 거래 시퀀스 사이에 임의의 계산을 삽입할 수 있습니다.

이것은 MEV의 작동 원리와 비슷하게 들리지만, MEV는 dApp 개발자를 위한 개방형 설계 공간이 아닙니다. 이는 최악의 경우 외부 MEV 보호를 추구하는 미지의 어두운 숲을 탐험하는 것과 같으며, 최선의 결과에만 의존할 수 있습니다.

Uniswap v4의 유연성이 새로운 세대의 dApp(또는 기존 dApp의 업그레이드)를 자극하여 실행 시퀀스의 프로그래머블성을 높일 수 있다고 가정해 보겠습니다. 이러한 dApp은 일반적으로 단일 체인(L1 또는 L2)에만 배포되므로, 우리는 대부분의 상태 변경이 해당 체인에서 실행될 것으로 예상합니다.

• dApp 상태 변경 과정에서 삽입된 추가 계산은 너무 복잡하고 번거로워 해당 체인에서 실행할 수 없을 수 있습니다. 우리는 곧 가스 한도를 초과하거나 아예 실행하기 어려울 수 있습니다. 또한 보안성과 조합성 측면에서 많은 도전 과제가 발생할 것입니다.

• 모든 계산이 평등한 것은 아닙니다. dApp이 오라클 및 자동화 네트워크와 같은 외부 프로토콜에 의존하는 것은 이를 증명합니다. 그러나 이러한 의존성은 보안 위험을 초래할 수 있습니다.

문제를 요약하자면: 모든 계산을 단일 체인에서 상태 변경의 스마트 계약 실행으로 통합하는 것은 최선의 방법이 아닙니다.

해결책 힌트: 현실 세계에서 이미 해결됨

새로운 세대의 dApp이 가져오는 이 문제(대부분 Uniswap v4에서 영감을 받았을 가능성이 있음)를 해결하기 위해, 우리는 문제의 핵심인 단일 체인에 대해 깊이 연구해야 합니다. 블록체인이 작동하는 방식은 분산 컴퓨터와 같으며, 모든 작업을 하나의 CPU가 처리합니다. 개인용 컴퓨터에서 현대 CPU는 이 문제를 해결하는 데 큰 발전을 이루었습니다.

컴퓨터가 단일 코어 단일 칩 CPU에서 여러 효율 코어, 성능 코어, GPU 및 NPU로 구성된 모듈화된 설계로 전환된 것처럼 말입니다.

dApp 계산도 유사한 방식으로 확장할 수 있습니다. 프로세서를 전문화하고 그 결과를 결합하여 일부 계산을 주요 프로세서 외부로 아웃소싱함으로써 유연성, 최적성, 보안성, 확장성 및 업그레이드 가능성을 실현할 수 있습니다.

실제 해결책

실제로 협처리기는 두 가지 유형만 있습니다:

• 외부 협처리기

• 내장형 협처리기

외부 협처리기

외부 협처리기는 클라우드 GPU와 유사하며, 사용하기 쉽고 강력하지만 CPU와 GPU 간의 통신에는 추가적인 네트워크 지연이 있습니다. 또한, GPU는 결국 당신이 제어할 수 없으므로, 그것이 올바르게 작업을 수행하고 있다고 믿어야 합니다.

Uniswap v4를 예로 들어 보겠습니다. 마지막 5분 TWAP 동안 일부 ETH와 USDC를 유동성 풀에 추가한다고 가정할 때, TWAP 계산이 Axiom에서 완료되면 Uniswap v4는 기본적으로 이더리움을 주요 프로세서로 사용하고 Axiom을 협처리기로 사용하는 것입니다.

Axiom

Axiom은 이더리움의 ZK 협처리기로, 스마트 계약에 모든 체인 상 데이터에 대한 신뢰할 필요 없는 접근과 데이터를 임의의 표현식으로 계산할 수 있는 능력을 제공합니다.

개발자는 Axiom에 쿼리를 수행하고, 스마트 계약 내에서 신뢰할 필요 없이 체인 상에서 제로 지식(ZK) 검증된 결과를 사용할 수 있습니다. 쿼리를 완료하기 위해 Axiom은 세 가지 단계를 수행합니다:

• 읽기: Axiom은 제로 지식 증명을 사용하여 신뢰할 필요 없이 과거 이더리움 블록의 블록 헤더, 상태, 거래 및 영수증의 읽기 데이터를 수정합니다. 모든 이더리움 체인 상 데이터는 이러한 형태 중 하나로 인코딩되어 있어, Axiom은 아카이브 노드가 접근할 수 있는 모든 데이터에 접근할 수 있습니다.

• 계산: 데이터를 가져온 후, Axiom은 이를 바탕으로 검증된 계산 원리를 적용합니다. 여기에는 기본 분석(합계, 개수, 최대값, 최소값)에서 암호화(서명 검증, 키 집합) 및 머신 러닝(결정 트리, 선형 회귀, 신경망 추론)까지 다양한 작업이 포함됩니다. 각 계산의 유효성은 제로 지식 증명에서 검증됩니다.

• 검증: Axiom은 각 쿼리 결과에 제로 지식 유효성 증명을 첨부하여 (1) 체인 상에서 입력 데이터를 올바르게 가져왔고, (2) 계산을 올바르게 적용했음을 증명합니다. 이 제로 지식 증명은 Axiom 스마트 계약에서 체인 상 검증을 수행한 후, 최종 결과는 모든 하위 스마트 계약에서 신뢰할 필요 없이 사용됩니다.

Warp 계약(레드스톤을 통해)

Warp 계약은 가장 일반적인 SmartWeave 구현으로, 이 아키텍처는 Arweave에서 신뢰할 수 있고 빠른 생산 준비형 스마트 계약 플랫폼/엔진을 생성하는 것을 목표로 합니다. 본질적으로 SmartWeave는 Arweave 거래의 정렬된 배열로, Arweave에서 거래 블록 수수료 시장의 부재로 혜택을 봅니다. 이러한 독특한 속성은 무한한 거래 데이터를 허용하며, 저장 비용 외에 추가 비용이 필요하지 않습니다.

SmartWeave는 "게으른 평가"라는 독특한 방법을 채택하여 스마트 계약 코드 실행의 책임을 네트워크 노드에서 스마트 계약 사용자로 전환합니다. 본질적으로 이는 거래 검증 계산이 필요할 때까지 연기되어 네트워크 노드의 작업 부하를 줄이고 거래를 더 효율적으로 처리할 수 있게 합니다. 이러한 방법을 통해 사용자는 필요에 따라 가능한 한 많은 계산을 수행할 수 있으며, 추가 비용이 발생하지 않아 다른 스마트 계약 시스템에서는 구현할 수 없는 기능을 제공합니다. 분명히, 수천 번의 상호작용을 가진 계약을 사용자의 CPU에서 평가하려고 시도하는 것은 결국 헛수고입니다. 이러한 도전을 극복하기 위해, Warp의 DRE와 같은 추상화 계층이 개발되었습니다. 이 추상화 계층은 계약 계산을 처리하는 분산 검증자 네트워크로 구성되어 있으며, 최종적으로 응답 시간을 크게 단축하고 사용자 경험을 개선할 수 있습니다.

또한 SmartWeave의 개방형 설계는 개발자가 어떤 프로그래밍 언어로든 논리를 작성할 수 있게 하여, 종종 경직된 Solidity 코드베이스에 대한 새로운 대안을 제공합니다. 특정 고비용 또는 고처리량 작업을 Warp에 위임함으로써, 원활한 SmartWeave 통합은 EVM 체인 기반의 기존 소셜 그래프 프로토콜을 강화하여 두 기술의 장점을 최대한 활용할 수 있습니다.

하이퍼 오라클

하이퍼 오라클은 블록체인을 위해 설계된 ZK 오라클 네트워크입니다. 현재 ZK 오라클 네트워크는 이더리움 블록체인에서만 운영됩니다. 이는 zkPoS를 사용하여 블록체인의 각 블록에서 데이터를 검색하고 이를 데이터 소스로 사용하며, zkWASM에서 실행되는 프로그래머블 zkGraph가 데이터를 처리하는 모든 작업이 신뢰할 필요 없고 안전한 방식으로 이루어집니다.

개발자는 JavaScript를 사용하여 사용자 정의 체인 외부 계산을 정의하고, 이러한 계산을 하이퍼 오라클 네트워크에 배포하며, 하이퍼 오라클 메타 앱을 활용하여 스마트 계약을 인덱싱하고 자동화할 수 있습니다.

하이퍼 오라클의 인덱싱 및 자동화 메타 앱은 완전히 사용자 정의 가능하고 매우 유연합니다. 모든 계산을 정의할 수 있으며, 모든 계산(심지어 머신 러닝 계산)도 생성된 제로 지식 증명으로 보호됩니다.

• 이더리움 블록체인은 ZK 오라클의 원래 체인 상 데이터 소스이지만, 미래에는 어떤 네트워크도 사용할 수 있습니다.

• 하이퍼 오라클 ZK 오라클 노드는 두 가지 주요 구성 요소로 구성됩니다: zkPoS 및 zkWASM.

• zkPoS는 제로 지식을 사용하여 이더리움의 합의를 증명하고, 이더리움 블록체인의 블록 헤더와 데이터 루트를 가져옵니다. 제로 지식 증명 생성 과정은 분산된 증명자 네트워크에 아웃소싱할 수 있습니다. zkPoS는 zkWASM의 외부 루프 역할을 합니다.

• zkPoS는 블록 헤더와 데이터 루트를 zkWASM에 제공합니다. zkWASM은 이 데이터를 zkGraph를 실행하는 기본 입력으로 사용합니다.

• zkWASM은 사용자 정의 데이터 매핑 또는 zkGraph가 정의한 다른 계산을 실행하고 이러한 작업의 제로 지식 증명을 생성합니다. ZK 오라클 노드의 운영자는 실행할 zkGraph의 수를 선택할 수 있습니다(하나에서 모든 배포된 zkGraph까지). 제로 지식 증명 생성 과정은 분산된 증명자 네트워크에 아웃소싱할 수 있습니다.

• ZK 오라클의 출력은 체인 외부 데이터이며, 개발자는 하이퍼 오라클 메타 앱을 통해 이 체인 외부 데이터를 사용할 수 있습니다(후속 장에서 소개될 예정입니다). 이 데이터는 또한 유효성과 계산 상태를 증명하는 제로 지식 증명과 함께 제공됩니다.

기타 주목할 만한 프로젝트

이러한 방식으로 채택하기로 결정한 경우, 외부 협처리기로 사용할 수 있는 몇 가지 프로젝트가 있습니다. 단지 이러한 프로젝트는 블록체인 인프라의 다른 수직 분야와 겹치며, 협처리기로 별도로 분류되지 않았습니다.

• RiscZero: dApp이 RiscZero를 사용하여 체인 상 에이전트의 머신 러닝 작업을 수행하고, 결과를 StarkNet의 게임 계약에 제공하는 경우, StarkNet을 주요 프로세서로 사용하고 RiscZero를 협처리기로 사용합니다.

• IronMill: dApp이 IronMill에서 zk 루프를 실행하지만, 이더리움에 스마트 계약을 배포하는 경우, 이더리움을 주요 프로세서로 사용하고 IronMill을 협처리기로 사용합니다.

외부 협처리기의 잠재적 사용 사례

• 거버넌스 및 투표: 역사적 체인 상 데이터는 분산 자치 조직(DAO)이 각 구성원이 보유한 투표권 수를 기록하는 데 도움이 될 수 있으며, 이는 투표에 필수적입니다. 이러한 데이터가 없으면 구성원은 투표 과정에 참여할 수 없으며, 이는 거버넌스를 저해할 수 있습니다.

• 인수: 역사적 체인 상 데이터는 자산 관리자가 수익 외의 성과를 평가하는 데 도움이 될 수 있습니다. 그들은 감수한 위험 수준과 경험한 철회 유형을 살펴볼 수 있으며, 이는 보상이나 잠재적 보상이 줄어들 때 더 현명한 결정을 내리는 데 도움이 됩니다.

• 분산 거래소: 체인 상의 역사적 가격 데이터는 분산 거래소가 과거의 추세와 패턴에 따라 거래를 수행하는 데 도움이 될 수 있으며, 사용자에게 더 높은 수익을 가져올 수 있습니다. 또한 역사적 거래 데이터는 거래소가 알고리즘과 사용자 경험을 개선하는 데 도움이 됩니다.

• 보험 상품: 보험 회사는 역사적 체인 상 데이터를 사용하여 위험을 평가하고 다양한 유형의 보험에 대해 보험료를 설정할 수 있습니다. 예를 들어, DeFi 프로젝트에 대한 보험료를 설정할 때 보험 회사는 과거의 체인 상 데이터를 살펴볼 수 있습니다.

위의 모든 사용 사례는 비동기 사용 사례라는 점에 유의하십시오. 고객 dApp이 블록 N에서 트리거될 때 외부 협처리기의 스마트 계약을 호출해야 합니다. 협처리기가 계산 결과를 반환할 때, 결과는 최소한 다음 블록(N+1)에서 어떤 형태로든 수용되거나 검증되어야 합니다. 이렇게 하면 최소한 다음 트리거 블록을 얻어야 협처리 결과를 활용할 수 있습니다. 이 패턴은 클라우드 GPU와 매우 유사합니다. 이는 머신 러닝 모델을 잘 실행할 수 있지만, 지연으로 인해 빠른 속도의 게임을 즐길 수는 없습니다.

내장형 협처리기

내장형 협처리기는 개인용 컴퓨터 메인보드의 GPU와 유사하며, CPU 옆에 위치합니다. GPU와 CPU 간의 통신 지연은 매우 작습니다. 또한 GPU는 완전히 제어할 수 있으므로, 변조되지 않았음을 확신할 수 있습니다. 다만, 클라우드 GPU처럼 신속하게 머신 러닝을 실행하려면 높은 비용이 발생해야 합니다.

여전히 Uniswap v4를 예로 들어 보겠습니다. 마지막 5분 TWAP 동안 일부 ETH와 USDC를 Artela에 배포된 유동성 풀에 추가한다고 가정할 때, 해당 풀이 Artela의 EVM에 배포되고 TWAP 계산이 Artela의 WASM에서 완료된다면, 해당 풀은 기본적으로 Artela의 EVM을 주요 프로세서로 사용하고 Artela의 WASM을 협처리기로 사용하는 것입니다.

Artela

Artela는 Tendermint BFT를 사용하여 구축된 L1입니다. 이는 체인 상에서 사용자 정의 기능을 지원하기 위해 임의의 실행 계층의 동적 확장을 지원하는 프레임워크를 제공합니다. 각 Artela 전체 노드는 두 개의 가상 머신을 동시에 실행합니다.

• EVM, 스마트 계약 상태를 저장하고 업데이트하는 주요 프로세서입니다.

• WASM, Aspect 상태를 저장하고 업데이트하는 협처리기입니다.

Aspects는 개발자가 스마트 계약 상태를 건드리지 않고 실행하고자 하는 임의의 계산을 나타냅니다. 이를 Rust 스크립트로 간주하여 dApp에 스마트 계약의 네이티브 조합성을 초과하는 사용자 정의 기능을 제공합니다.

이 점이 이해가 되지 않는다면, 다음 두 가지 관점에서 살펴보십시오:

• 블록체인 아키텍처 관점에서

• Aspect는 새로운 실행 계층입니다.

• Artela에서는 블록체인이 동시에 두 개의 실행 계층을 실행합니다. 하나는 스마트 계약을 위한 것이고, 다른 하나는 기타 계산을 위한 것입니다.

• 이 새로운 실행 계층은 새로운 신뢰 가정을 도입하지 않으므로 블록체인 자체의 보안성에 영향을 미치지 않습니다. 두 개의 가상 머신은 동일한 합의를 실행하는 동일한 노드 그룹에 의해 보호됩니다.

• 애플리케이션 런타임 관점에서

• Aspects는 스마트 계약과 협력하여 작동하는 프로그래머블 모듈로, 사용자 정의 기능 추가 및 독립 실행을 지원합니다.

• 이는 여러 면에서 단일 스마트 계약보다 더 유리합니다:

  -- 비침투성: 스마트 계약 코드를 수정하지 않고도 계약 실행 전후에 개입할 수 있습니다.

  -- 동기 실행: 거래 생애 주기 전반에 걸쳐 훅 논리를 지원하여 세밀한 사용자 정의를 허용합니다.

  -- 전역 상태 및 기본 계층 구성에 직접 접근하여 시스템 수준 기능을 지원합니다.

  -- 탄력적인 블록 공간: 거래 처리량 요구가 높은 dApp에 대해 프로토콜 보장된 독립 블록 공간을 제공합니다.

  -- 정적 프리컴파일과 비교하여 dApp이 런타임에 동적이고 모듈화된 업그레이드를 구현하여 안정성과 유연성을 균형 있게 유지할 수 있도록 지원합니다.

이러한 내장형 협처리기를 도입함으로써 Artela는 흥미로운 돌파구를 마련했습니다. 이제 임의의 확장 모듈인 Aspects는 스마트 계약과 동일한 거래를 통해 실행될 수 있습니다. 개발자는 자신의 스마트 계약을 Aspects에 바인딩하고, 스마트 계약을 호출하는 모든 거래가 Aspects에 의해 처리되도록 할 수 있습니다.

또한, 스마트 계약과 마찬가지로 Aspects는 체인 상에 데이터를 저장하며, 스마트 계약과 Aspects가 서로의 전역 상태를 읽을 수 있도록 지원합니다.

이 두 가지 기능은 스마트 계약과 Aspects 간의 조합성과 상호 운용성을 크게 향상시킵니다.

• Aspect 기능:

  스마트 계약과 비교할 때, Aspects가 제공하는 기능은 주로 거래 전후 실행에 중점을 둡니다. Aspects는 스마트 계약을 대체하는 것이 아니라 보완합니다. 스마트 계약과 비교할 때, Aspects는 애플리케이션에 다음과 같은 독특한 기능을 제공합니다:

• 신뢰할 수 있는 거래를 역전된 블록에 자동으로 삽입합니다(예: 예정된 작업에 사용).

• 거래로 인한 상태 데이터 변화의 역전(오직 승인된 계약 거래만 역전 가능).

• 정적 환경 변수를 읽습니다.

• 임시 실행 상태를 하위 Aspects로 전달합니다.

• 상위 Aspect에서 전달된 임시 실행 상태를 읽습니다.

• 동적이고 모듈화된 업그레이드 가능성.

• Aspect와 스마트 계약의 차이점:

  Aspect와 스마트 계약의 차이점은 다음과 같습니다:

• 스마트 계약은 코드가 포함된 계정인 반면, Aspect는 블록체인의 네이티브 확장입니다.

• Aspect는 거래 및 블록 생애 주기의 다양한 지점에서 실행될 수 있으며, 스마트 계약은 고정된 지점에서만 실행됩니다.

• 스마트 계약은 자신의 상태와 블록의 제한된 맥락에 접근할 수 있는 반면, Aspect는 전역 처리 맥락 및 시스템 수준 API와 상호작용할 수 있습니다.

• Aspect의 실행 환경은 원주율 속도에 가깝게 설계되었습니다.

  Aspect는 코드 논리 조각일 뿐이며, 계정과는 무관하므로 다음과 같은 작업을 수행할 수 없습니다:

• 계약 상태 데이터를 작성, 수정 또는 삭제할 수 없습니다.

• 새로운 계약을 생성할 수 없습니다.

• 원주율 토큰을 이체, 소각 또는 보유할 수 없습니다.

이러한 Aspect는 Artela를 독특한 플랫폼으로 만들어, 스마트 계약의 기능을 확장하고 더 포괄적이고 사용자 정의 가능성이 높은 개발 환경을 제공합니다.

*주의: 엄밀히 말하면, 위의 Aspect는 "내장형" Aspect라고도 하며, Artela 체인 전체 노드에서 실행되는 내장형 협처리기입니다. dApp은 또한 외부 협처리기에 의해 실행되는 자신의 이종 Aspect를 배포할 수 있습니다. 이러한 외부 협처리기는 외부 네트워크에서 실행되거나 다른 합의의 노드 하위 집합에 의해 실행될 수 있습니다. 이는 더 유연하며, dApp 개발자는 실제로 안전하고 합리적인 작업을 수행할 수 있는 한 원하는 작업을 수행할 수 있습니다. 현재 여전히 탐색 중이며, 구체적인 세부 사항은 아직 발표되지 않았습니다.

내장형 협처리기의 잠재적 사용 사례

• 새로운 DeFi 프로젝트에서 복잡한 계산(예: 복잡한 게임 이론 메커니즘)이 포함될 수 있으며, 이는 내장형 협처리기가 더 높은 유연성과 반복성을 가진 즉각적인 계산 능력을 필요로 할 수 있습니다.

• 다양한 dApp에 대한 더 유연한 접근 제어 메커니즘. 현재 접근 제어는 일반적으로 스마트 계약 권한에 기반한 블랙리스트 또는 화이트리스트로 제한됩니다. 내장형 협처리기는 즉각적이고 세밀한 접근 제어 수준을 잠금 해제할 수 있습니다.

• 전체 체인 게임(FOCG)의 특정 복잡한 기능. FOCG는 오랫동안 EVM의 제한을 받아왔습니다. EVM이 NFT 및 토큰과 같은 더 간단한 기능을 유지하고, 다른 논리 및 상태 업데이트는 협처리가 계산된다면 상황이 더 간단해질 수 있습니다.

• 보안 메커니즘. dApp은 자신의 능동적 보안 모니터링 및 실패 안전 메커니즘을 도입할 수 있습니다. 예를 들어, 유동성 풀은 10분마다 5% 이상의 인출을 차단할 수 있습니다. 만약 협처리가 그 중 하나의 인출을 감지하면, 스마트 계약은 중단되고 특정 동적 가격 범위 내에서 긴급 유동성을 주입하는 등의 경고 메커니즘을 트리거할 수 있습니다.

결론

dApp이 커지고 비대해지며 지나치게 복잡해지는 것은 불가피하며, 따라서 협처리기의 보급도 필연적입니다. 이는 단지 시간과 채택 곡선의 문제일 뿐입니다.

외부 협처리기를 운영하면 dApp이 자신의 편안한 영역에 머물 수 있습니다: 이전에 어느 체인에 있었든지 간에 말입니다. 그러나 배포할 실행 환경을 찾고 있는 새로운 dApp 개발자에게 내장형 협처리기는 개인용 컴퓨터의 GPU와 같습니다. 고성능 개인용 컴퓨터라고 주장하려면, 적절한 GPU를 보유해야 합니다.

안타깝게도, 위의 프로젝트는 아직 메인넷에 출시되지 않았습니다. 우리는 실제로 벤치마크 테스트를 수행할 수 없으며, 어떤 프로젝트가 어떤 사용 사례에 더 적합한지 보여줄 수 없습니다. 그러나 한 가지는 확실합니다. 기술은 나선형으로 발전하고 있습니다. 우리는 제자리에서 돌고 있는 것처럼 보이지만, 측면에서 보면 역사는 기술이 실제로 발전하고 있음을 증명할 것입니다.

확장성 불가능한 삼각형 만세, 협처리기 만세.