원작자: 힐
이 기사는 SevenX 연구팀이 작성한 원본이며 커뮤니케이션 및 학습 목적으로만 작성되었으며 투자 참고 자료가 아닙니다. 인용이 필요하신 경우 출처를 표기해주세요.
최근 Uniswap v4가 출시되었으며, 기능이 아직 완성되지 않았지만 커뮤니티가 전례 없는 가능성을 광범위하게 탐색할 수 있기를 바랍니다. DeFi 분야에서 Uniswap v4의 막대한 영향력을 소개하는 기사가 많이 있을 수 있다는 점을 고려하여, 이 기사에서는 Uniswap v4가 새로운 블록체인 인프라인 코프로세서(코프로세서)에 어떻게 영감을 주는지 살펴보겠습니다.
Uniswap v4 소개
백서에 명시된 바와 같이 Uniswap v4에는 4가지 주요 개선 사항이 있습니다.
후크: 후크는 풀 실행 중 지정된 지점에서 개발자가 정의한 논리를 실행하는 외부 배포 계약입니다. 이러한 후크를 통해 통합자는 유연하고 사용자 정의 가능한 실행을 통해 중앙 집중식 유동성 풀을 생성할 수 있습니다.
싱글톤: Uniswap v4는 모든 풀이 단일 계약으로 관리되는 싱글톤 설계 패턴을 채택하여 풀 배포 비용을 99% 절감합니다.
플래시 회계: 각 작업은 델타라고도 하는 내부 순 잔고를 업데이트하고 잠금이 끝날 때만 외부 전송을 수행합니다. Lightning 회계는 원자 교환 및 추가와 같은 복잡한 풀 작업을 단순화합니다.
기본 ETH: WETH 및 ETH 거래 쌍을 지원합니다.
가스 절감의 대부분은 지난 세 가지 개선 사항에서 비롯되었지만 의심할 여지 없이 가장 흥미로운 새 기능은 이 기사의 시작 부분에서 언급한 기능인 후크입니다.
후크는 유동성 풀을 더욱 복잡하고 강력하게 만듭니다.
Uniswap v4의 주요 개선 사항은 후크 잠금 해제 프로그래밍 가능성에 관한 것입니다. 이 기능은 유동성 풀을 더욱 복잡하고 강력하게 만들어 이전보다 더 유연하고 맞춤화할 수 있게 해줍니다. Uniswap v3의 중앙 집중식 유동성(Uniswap v2의 순 업그레이드)과 비교하여 Uniswap v4의 후크는 유동성 풀이 작동하는 방식에 대한 더 넓은 범위의 가능성을 제공합니다.
이번 릴리스는 Uniswap v3에 대한 전체 업그레이드로 간주될 수 있지만 실제로 구현되면 그렇지 않을 수도 있습니다. Uniswap v3 풀은 항상 Uniswap v2 풀에 비해 업그레이드입니다. 왜냐하면 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의 장점을 통해 유동성 풀 스마트 계약이 새로운 프로그래밍 가능 업그레이드를 받아 더 똑똑해졌습니다. Nokia에서 iPhone으로 업그레이드할 수 있는 기회가 주어졌을 때 모든 dApp이 이 방향으로 업그레이드하고 싶어하는 것은 아닌 이유를 알 수 없습니다. Nokia는 iPhone보다 신뢰성이 높기 때문에 현 상태를 유지하려는 일부 스마트 계약을 이해할 수 있지만 dApp이 미래에 어디로 향할지에 대해 이야기하고 있습니다.
dApp은 확장 문제를 일으키는 자체 후크를 사용하려고 합니다.
이것을 다른 모든 dApp에 적용한다고 상상해보세요. 조건을 삽입하여 트리거한 다음 원시 트랜잭션 시퀀스 사이에 임의의 계산을 삽입할 수 있습니다.
이는 MEV가 작동하는 방식처럼 들리지만 MEV는 dApp 개발자를 위한 개방형 설계 공간이 아닙니다. 그것은 기껏해야 외부 MEV 보호를 찾고 최선을 다하는 미지의 어두운 숲으로의 하이킹과 비슷했습니다.
Uniswap v4의 유연성은 새로운 세대의 dApp(또는 기존 dApp의 업그레이드)이 유사한 철학을 채택하도록 영감을 주어 실행 순서를 더욱 프로그래밍 가능하게 만드는 것으로 가정됩니다. 이러한 dApp은 일반적으로 하나의 체인(L1 또는 L2)에만 배포되므로 대부분의 상태 변경이 해당 체인에서 실행될 것으로 예상됩니다.
dApp 상태 변경 중에 삽입된 추가 계산은 체인에서 실행하기에는 너무 복잡하고 번거로울 수 있습니다. 가스 한도를 빠르게 초과할 수도 있고 전혀 불가능할 수도 있습니다. 또한 특히 보안 및 구성 가능성 측면에서 많은 문제가 발생합니다.
모든 계산이 동일하게 생성되는 것은 아닙니다. 이는 오라클 및 자동화된 네트워크와 같은 외부 프로토콜에 대한 dApp의 의존도에서 입증됩니다. 그러나 이러한 의존은 보안 위험을 초래할 수 있습니다.
문제를 요약하면 모든 계산을 단일 체인의 상태 변경 스마트 계약 실행에 통합하는 것은 최적이 아닙니다.
솔루션 팁: 이미 현실 세계에서 해결됨
차세대 dApp(아마도 Uniswap v4에서 많은 영감을 받았음)으로 인해 발생한 이 문제를 해결하려면 문제의 핵심인 이 단일 체인을 조사해야 합니다. 블록체인은 단일 CPU를 사용하여 모든 작업을 처리하는 분산 컴퓨터처럼 작동합니다. PC에서 최신 CPU는 이 문제를 해결하는 데 큰 진전을 이루었습니다.
컴퓨터가 단일 코어 모놀리식 CPU에서 여러 효율성 코어, 성능 코어, GPU 및 NPU로 구성된 모듈형 설계로 전환한 것과 같습니다.
dApp 컴퓨팅도 비슷한 방식으로 확장할 수 있습니다. 유연성, 최적성, 보안, 확장성 및 업그레이드 가능성은 프로세서를 전문화하고 이들의 노력을 결합하여 일부 계산을 메인 프로세서에서 아웃소싱함으로써 달성할 수 있습니다.
실용적인 솔루션
실제로 보조 프로세서에는 두 가지 유형만 있습니다.
외부 보조 프로세서
임베디드 보조 프로세서
외부 보조 프로세서
외부 보조 프로세서는 사용하기 쉽고 강력하다는 점에서 클라우드 GPU와 유사하지만 CPU와 GPU 통신 사이에 추가 네트워크 대기 시간이 있습니다. 게다가 궁극적으로 GPU를 제어하는 것이 아니므로 GPU가 제대로 작동하고 있는지 신뢰해야 합니다.
Uniswap v4를 예로 들면, 지난 5분 동안 TWAP 중에 일부 ETH와 USDC가 유동성 풀에 추가되었다고 가정하면 Axiom에서 TWAP 계산이 완료되면 Uniswap v4는 기본적으로 Ethereum을 메인 프로세서로, Axiom을 협력자로 사용합니다. .프로세서.
Axiom
Axiom은 Ethereum의 ZK 보조 프로세서로, 모든 온체인 데이터에 대한 무신뢰 액세스와 데이터에 대한 임의 표현 계산을 수행할 수 있는 기능을 스마트 계약에 제공합니다.
개발자는 Axiom에 문의하고 스마트 계약에서 무신뢰 방식으로 온체인 영지식(ZK) 검증 결과를 사용할 수 있습니다. 쿼리를 완료하기 위해 Axiom은 세 단계를 수행합니다.
읽기: Axiom은 영지식 증명을 사용하여 과거 이더리움 블록의 블록 헤더, 상태, 트랜잭션 및 영수증에 대한 읽기 데이터를 무신뢰 없이 수정합니다. 모든 Ethereum 온체인 데이터는 이러한 형식 중 하나로 인코딩됩니다. 즉, Axiom은 아카이브 노드에 액세스할 수 있는 모든 데이터에 액세스할 수 있습니다.
계산: 데이터가 획득되면 Axiom은 이에 대해 입증된 계산 기본 요소를 적용합니다. 여기에는 기본 분석(합계, 개수, 최대, 최소)부터 암호화(서명 확인, 키 집계) 및 기계 학습(의사결정 트리, 선형 회귀, 신경망 추론)에 이르는 작업이 포함됩니다. 모든 계산의 유효성은 영지식 증명을 통해 검증됩니다.
검증: Axiom은 각 쿼리 결과에 대한 영지식 유효성 증명을 제공하여 (1) 입력 데이터가 체인에서 올바르게 가져왔고 (2) 계산이 올바르게 적용되었음을 증명합니다. 이 영지식 증명은 Axiom 스마트 계약의 온체인으로 검증되며, 최종 결과는 무신뢰 방식으로 모든 다운스트림 스마트 계약에 제공됩니다.
워프 계약(RedStone을 통해)
Warp 계약은 가장 일반적인 SmartWeave 구현으로, Arweave에서 안정적이고 빠르며 생산 준비가 완료된 스마트 계약 플랫폼/엔진을 생성하도록 설계된 아키텍처입니다. 본질적으로 SmartWeave는 Arweave에 거래 블록 포함 수수료 시장이 없다는 이점을 활용하는 Arweave 거래의 정렬된 배열입니다. 이러한 고유한 속성을 통해 저장 비용 외에 추가 비용 없이 무제한 거래 데이터를 사용할 수 있습니다.
SmartWeave는 지연 평가라는 고유한 접근 방식을 사용하여 스마트 계약 코드 실행에 대한 책임을 네트워크 노드에서 스마트 계약 사용자로 전환합니다. 본질적으로 이는 트랜잭션 확인을 위한 계산이 필요할 때까지 연기되어 네트워크 노드의 작업 부하를 줄이고 트랜잭션을 보다 효율적으로 처리할 수 있음을 의미합니다. 이 접근 방식을 사용하면 사용자는 추가 비용 없이 원하는 만큼 많은 계산을 수행할 수 있어 다른 스마트 계약 시스템에서는 불가능한 기능을 제공합니다. 분명히 사용자의 CPU에서 수천 번의 상호 작용이 포함된 계약을 평가하려는 시도는 궁극적으로 소용이 없습니다. 이러한 문제를 극복하기 위해 Warp의 DRE와 같은 추상화 계층이 개발되었습니다. 이 추상화 계층은 계약 계산을 처리하는 분산 검증기 네트워크로 구성되어 궁극적으로 응답 시간이 훨씬 빨라지고 사용자 경험이 향상됩니다.
또한 SmartWeave의 개방형 설계를 통해 개발자는 모든 프로그래밍 언어로 논리를 작성할 수 있어 종종 경직된 Solidity 코드 기반에 대한 새로운 대안을 제공합니다. 원활한 SmartWeave 통합은 두 기술의 이점을 활용하여 특정 고비용 또는 고처리량 작업을 Warp에 위임함으로써 EVM 체인에 구축된 기존 소셜 그래프 프로토콜을 향상시킵니다.
Hyper Oracle
Hyper Oracle은 블록체인을 위해 특별히 설계된 ZK Oracle 네트워크입니다. 현재 ZK Oracle 네트워크는 Ethereum 블록체인에서만 운영됩니다. zkPoS를 사용하여 블록체인의 각 블록에서 데이터 소스로 데이터를 검색하는 동시에 zkWASM에서 실행되는 프로그래밍 가능한 zkGraph를 사용하여 데이터를 처리하는 동시에 신뢰할 수 없고 안전한 방식으로 수행됩니다.
개발자는 JavaScript를 사용하여 맞춤형 오프체인 계산을 정의하고, 이러한 계산을 Hyper Oracle 네트워크에 배포하고, Hyper Oracle Meta Apps를 활용하여 스마트 계약을 색인화하고 자동화할 수 있습니다.
Hyper Oracle의 인덱싱 및 자동화 Meta Apps는 완전히 사용자 정의 가능하고 유연합니다. 어떤 계산이든 정의할 수 있으며 모든 계산(기계 학습 계산 포함)은 생성된 영지식 증명으로 보호됩니다.
이더리움 블록체인은 ZK 오라클을 위한 최초의 온체인 데이터 소스이지만 향후 모든 네트워크를 사용할 수 있습니다.
Hyper Oracle ZK Oracle 노드는 zkPoS와 zkWASM의 두 가지 주요 구성 요소로 구성됩니다.
- zkPoS는 영지식을 사용하여 이더리움의 합의를 증명하고 이더리움 블록체인의 블록 헤더와 데이터 루트를 얻습니다. 영지식 증명 생성 프로세스는 분산형 증명자 네트워크에 아웃소싱될 수 있습니다. zkPoS는 zkWASM의 외부 루프 역할을 합니다.
- zkPoS는 zkWASM에 블록 헤더와 데이터 루트를 제공합니다. zkWASM은 이 데이터를 zkGraph 실행을 위한 기본 입력으로 사용합니다.
-zkWASM 사용자 정의 데이터 맵 또는 zkGraph에서 정의한 기타 계산을 실행하고 이러한 작업에 대한 영지식 증명을 생성합니다. ZK Oracle 노드의 운영자는 실행하려는 zkGraph의 수를 선택할 수 있습니다(하나부터 배포된 모든 zkGraph까지). 영지식 증명 생성 프로세스는 분산형 증명자 네트워크에 아웃소싱될 수 있습니다.
ZK 오라클은 오프체인 데이터를 출력하며, 개발자는 Hyper Oracle Meta Apps(다음 장에서 소개 예정)를 통해 이 오프체인 데이터를 사용할 수 있습니다. 데이터에는 유효성과 계산을 입증하는 영지식 증명도 함께 제공됩니다.
기타 언급할만한 항목
이 경로를 선택하기로 결정한 경우 외부 보조 프로세서로 사용할 수 있는 프로젝트도 있습니다. 다만 이러한 프로젝트는 블록체인 인프라의 다른 수직 영역과 겹치며 별도로 공동 프로세서로 분류되지 않습니다.
RiscZero: dApp이 RiscZero를 사용하여 체인의 에이전트에 대한 기계 학습 작업을 계산하고 StarkNet의 게임 계약에 결과를 제공하는 경우 StarkNet을 메인 프로세서로 사용하고 RiscZero를 보조 프로세서로 사용합니다.
IronMill: dApp이 IronMill에서 zk 루프를 실행하지만 Ethereum에 스마트 계약을 배포하는 경우 Ethereum을 주 프로세서로 사용하고 IronMill을 보조 프로세서로 사용합니다.
외부 보조 프로세서의 잠재적인 사용 사례
거버넌스 및 투표: 과거 온체인 데이터는 분산형 자율 조직(DAO)이 투표에 필수적인 각 구성원이 보유한 투표권 수를 기록하는 데 도움이 될 수 있습니다. 이 데이터가 없으면 회원은 투표 과정에 참여할 수 없어 거버넌스에 방해가 될 수 있습니다.
인수: 과거 온체인 데이터는 자산 관리자가 이익을 넘어 관리자의 성과를 평가하는 데 도움이 될 수 있습니다. 그들은 자신이 감수하고 있는 위험 수준과 경험하고 있는 손실 유형을 확인할 수 있으므로 보상이나 잠재적 보상이 줄어들 때 더 많은 정보를 바탕으로 결정을 내리는 데 도움이 됩니다.
분산형 거래소: 체인의 과거 가격 데이터는 분산형 거래소가 과거 추세와 패턴을 기반으로 거래하는 데 도움이 되어 잠재적으로 사용자에게 더 높은 수익을 가져다 줄 수 있습니다. 또한 과거 거래 데이터는 거래소가 알고리즘과 사용자 경험을 개선하는 데 도움이 됩니다.
보험 상품: 보험 회사는 과거 온체인 데이터를 사용하여 위험을 평가하고 다양한 유형의 보험에 대한 보험료를 설정할 수 있습니다. 예를 들어, DeFi 프로젝트에 대한 보험료를 설정할 때 보험 회사는 과거 온체인 데이터를 살펴볼 수 있습니다.
블록 N에서 트리거될 때 클라이언트 dApp이 외부 보조 프로세서의 스마트 계약을 호출해야 하기 때문에 위의 모든 사용 사례는 비동기식입니다. 보조 프로세서가 계산 결과를 반환할 때 결과는 적어도 다음 블록(예: N+1)에서 어떤 형태로든 승인되거나 검증되어야 합니다. 이러한 방식으로, 공동 처리 결과를 활용하기 위해 최소한 다음 트리거 블록이 획득됩니다. 이 모델은 클라우드 GPU와 정말 비슷합니다. 기계 학습 모델을 잘 실행할 수 있지만 대기 시간으로 인해 빠르게 진행되는 게임을 즐겁게 플레이할 수는 없습니다.
임베디드 보조 프로세서
내장형 보조 프로세서는 CPU 옆에 있는 PC 마더보드의 GPU와 유사합니다. GPU-CPU 통신 지연 시간은 매우 작습니다. 그리고 GPU는 완전히 사용자가 제어할 수 있으므로 GPU가 조작되지 않았음을 확신할 수 있습니다. 클라우드 GPU만큼 빠르게 머신러닝을 실행하려면 비용이 많이 듭니다.
여전히 Uniswap v4를 예로 들어 보겠습니다. TWAP의 마지막 5분 동안 Artela에 배포된 유동성 풀에 일부 ETH 및 USDC가 추가된다고 가정할 때, 풀이 Artela의 EVM에 배포되고 TWAP 계산이 Aretla의 WASM에서 수행되면 풀은 기본적으로 다음을 사용합니다. Artela의 EVM은 메인 프로세서로, Artela의 WASM은 보조 프로세서로 사용됩니다.
Artela
Artela는 Tendermint BFT를 사용하여 구축된 L1입니다. 온체인 사용자 정의 기능을 구현하기 위해 모든 실행 계층의 동적 확장을 지원하는 프레임워크를 제공합니다. 각 Artela 전체 노드는 두 개의 가상 머신을 동시에 실행합니다.
EVM은 스마트 계약 상태를 저장하고 업데이트하는 메인 프로세서입니다.
WASM은 측면 상태를 저장하고 업데이트하는 보조 프로세서입니다.
측면은 개발자가 스마트 계약 상태를 건드리지 않고 실행하려는 임의의 계산을 나타냅니다. 스마트 계약의 기본 구성 가능성을 넘어서는 맞춤형 기능을 dApp에 제공하는 Rust 스크립트라고 생각하세요.
이해하기 어렵다면 다음 두 가지 관점에서 생각해 볼 수 있습니다.
블록체인 아키텍처의 관점에서
- Aspect는 새로운 실행 레이어입니다.
- Artela에서 블록체인은 두 개의 실행 레이어를 동시에 실행합니다. 하나는 스마트 계약용이고 다른 하나는 기타 계산용입니다.
- 이 새로운 실행 계층은 새로운 신뢰 가정을 도입하지 않으므로 블록체인 자체의 보안에 영향을 미치지 않습니다. 두 VM 모두 동일한 합의를 실행하는 동일한 노드 집합으로 보호됩니다.
애플리케이션 런타임 관점에서
- Aspect는 스마트 계약과 함께 작동하는 프로그래밍 가능한 모듈로, 맞춤형 기능 추가 및 독립적 실행을 지원합니다.
- 여러 측면에서 단일 스마트 계약에 비해 장점이 있습니다.
-- Non-intrusive: 스마트 계약 코드를 수정하지 않고도 계약 실행 전후에 개입할 수 있습니다.
-- 동기식 실행: 전체 트랜잭션 수명 주기에 걸쳐 후크 논리를 지원하여 정교한 사용자 정의가 가능합니다.
-- 글로벌 상태 및 기본 계층 구성에 직접 액세스하여 시스템 수준 기능을 지원합니다.
-- 유연한 블록 공간: 트랜잭션 처리량 요구 사항이 더 높은 dApp을 위해 프로토콜이 보장되는 독립 블록 공간을 제공합니다.
-- 정적 사전 컴파일과 비교하여 안정성과 유연성의 균형을 맞추기 위해 런타임에 동적 및 모듈식 업그레이드를 달성할 수 있도록 dApp을 지원합니다.
이 임베디드 보조 프로세서를 도입함으로써 Artela는 흥미로운 혁신을 달성했습니다. 이제 스마트 계약과 동일한 트랜잭션을 통해 임의의 확장 모듈 측면을 실행할 수 있습니다. 개발자는 스마트 계약을 Aspect에 바인딩하고 스마트 계약을 호출하는 모든 트랜잭션을 Aspect에서 처리하도록 할 수 있습니다. .
또한 스마트 계약과 마찬가지로 Aspect는 체인에 데이터를 저장하므로 스마트 계약과 Aspect가 서로의 전역 상태를 읽을 수 있습니다.
이 두 가지 기능은 스마트 계약과 측면 간의 구성성과 상호 운용성을 크게 향상시킵니다.
측면 기능:
스마트 계약과 비교하여 Aspects가 제공하는 기능은 주로 거래 전후 실행에 중점을 둡니다. 측면은 스마트 계약을 대체하는 것이 아니라 보완합니다. 스마트 계약과 비교하여 Aspect는 애플리케이션에 다음과 같은 고유한 기능을 제공합니다.
- 신뢰할 수 있는 트랜잭션을 거꾸로 된 블록에 자동으로 삽입합니다(예: 예약된 작업의 경우).
- 거래로 인한 상태 데이터 변경 취소(승인된 계약 거래만 취소 가능)
- 정적 환경 변수를 읽습니다.
- 임시 실행 상태를 다운스트림의 다른 측면에 전달합니다.
- 업스트림 Aspect에서 전달된 임시 실행 상태를 읽습니다.
- 동적 및 모듈식 업그레이드 가능성.
측면과 스마트 계약의 차이점:
측면과 스마트 계약의 차이점은 다음과 같습니다.
- 스마트 계약은 코드가 포함된 계정인 반면 측면은 블록체인의 기본 확장입니다.
- 측면은 트랜잭션 및 블록 수명주기의 다양한 지점에서 실행될 수 있지만 스마트 계약은 고정된 지점에서만 실행됩니다.
- 스마트 계약은 자체 상태와 블록의 제한된 컨텍스트에 액세스할 수 있는 반면, 측면은 글로벌 처리 컨텍스트 및 시스템 수준 API와 상호 작용할 수 있습니다.
- Aspect의 실행 환경은 거의 기본 속도에 맞게 설계되었습니다.
Aspect는 코드 로직의 일부일 뿐이며 계정과 관련이 없으므로 다음을 수행할 수 없습니다.
- 계약현황 데이터를 작성, 수정, 삭제합니다.
- 새로운 계약을 작성하세요.
- 기본 토큰을 전송, 파괴 또는 보유합니다.
이러한 측면을 통해 Artela는 스마트 계약의 기능을 확장하고 보다 포괄적이고 사용자 정의 가능한 개발 환경을 제공할 수 있는 독특한 플랫폼이 되었습니다.
*엄밀히 말하면 위의 Aspect는 Artela Chain 풀 노드에서 실행되는 임베디드 코프로세서인 내장 Aspect라고도 합니다. dApp은 외부 보조 프로세서에 의해 실행되는 자체 이기종 측면을 배포할 수도 있습니다. 이러한 외부 코프로세서는 외부 네트워크에서 실행되거나 다른 합의에 있는 노드의 하위 집합에 의해 실행될 수 있습니다. dApp 개발자는 안전하고 합리적인 한 실제로 원하는 것은 무엇이든 할 수 있기 때문에 더 유연합니다. 아직 조사 중이며 구체적인 내용은 아직 발표되지 않았습니다.
임베디드 보조 프로세서의 잠재적인 사용 사례
복잡한 게임 이론 메커니즘과 같은 새로운 DeFi 프로젝트와 관련된 복잡한 계산에는 임베디드 보조 프로세서의 보다 유연하고 반복적인 즉석 컴퓨팅 성능이 필요할 수 있습니다.
다양한 dApp에 대한 보다 유연한 액세스 제어 메커니즘입니다. 현재 액세스 제어는 일반적으로 스마트 계약 권한을 기반으로 블랙리스트 또는 화이트리스트로 제한됩니다. 내장된 보조 프로세서는 즉각적이고 세부적인 수준의 액세스 제어를 제공합니다.
풀 체인 게임(FOCG)의 특정 복잡한 기능. FOCG는 오랫동안 EVM에 의해 제한되었습니다. EVM이 NFT 및 토큰 전송과 같은 간단한 기능을 유지하는 동시에 다른 로직 및 상태 업데이트가 보조 프로세서에 의해 계산된다면 더 간단할 수 있습니다.
보안 메커니즘. dApp은 자체 활성 보안 모니터링 및 오류 방지 메커니즘을 도입할 수 있습니다. 예를 들어 유동성 풀은 10분마다 5%를 초과하는 인출을 차단할 수 있습니다. 코프로세서가 인출 중 하나를 감지하면 스마트 계약은 특정 동적 가격 범위 내에서 긴급 유동성 주입과 같은 일부 경고 메커니즘을 중지하고 트리거할 수 있습니다.
결론
dApp이 커지고, 비대해지고, 지나치게 복잡해지는 것은 불가피하므로 보조 프로세서가 더 대중화되는 것은 불가피합니다. 단지 시간과 채택 곡선의 문제일 뿐입니다.
외부 보조 프로세서를 실행하면 dApp이 이전에 어떤 체인에 있었든 상관없이 편안한 영역에 머물 수 있습니다. 그러나 배포 가능한 실행 환경을 찾는 새로운 dApp 개발자에게 임베디드 보조 프로세서는 PC의 GPU와 같습니다. 고성능 PC라고 부르려면 괜찮은 GPU가 있어야 합니다.
아쉽게도 위 프로젝트들은 아직 메인넷에 출시되지 않았습니다. 어떤 프로젝트가 어떤 사용 사례에 더 적합한지 실제로 벤치마킹하고 보여줄 수는 없습니다. 그러나 한 가지 부인할 수 없는 것은 기술이 상승세를 타고 있다는 것입니다. 우리가 순환하는 것처럼 보일 수도 있지만, 측면에서 보면 기술이 실제로 진화한다는 것을 역사가 보게 될 것임을 기억하십시오.
확장성 삼각형이 영원하고 보조 프로세서도 영원합니다.
