스마트 계약이 '바이낸스'에서 거래될 수 있다면 어떨까요? 디씨파이(DeCeFi) 패러다임 소개합니다.
DeCeFi는 온체인 사용자와 스마트 계약이 블록체인을 벗어나지 않고도 CEX 수준의 실행 및 풍부한 유동성에 직접 접근할 수 있는 패러다임 입니다.
요약
DeFi는 프로그래밍이 가능하지만 실행력이 약합니다. 중앙거래소(CEX)는 강력하지만 직접 호출할 수 없습니다. 스마트 계약은 바이낸스와 같은 고성능 거래 엔진이나 하이퍼리퀴드와 같은 고급 주문장 플랫폼을 직접 호출할 수 없습니다. 표현력이 풍부한 실행과 온체인 프로그래밍 기능은 아직 완전히 결합되지 못했습니다.
128.trade는 스마트 계약이 최우선 순위로 자리매김하는 DeCeFi를 선보입니다. 모든 블록체인의 모든 계약은 자산 연결이나 네트워크 전환 없이 검증 가능한 게이트웨이를 통해 거래소 수준의 현물 및 무기한 거래를 실행할 수 있습니다.
128.trade는 거래 플랫폼이 아니라 거래 인프라입니다. 실행 호출을 가능하게 함으로써, 거래는 프로토콜이 실제 실행을 통해 헤지, 리밸런싱, 자본 등에 활용할 수 있는 결합 가능성(Composable DeFi) 기본 요소가 됩니다.
더 자세한 내용은 https://www.128.trade 에서 확인하세요.
배경 및 동기
거래와 DeFi는 진정으로 만난 적이 없다
탈중앙화 금융은 본질적으로 프로그래밍이 가능하며, 최고의 거래소에서의 거래는 표현력이 풍부하고 성능이 뛰어납니다. 그러나 지난 10년 동안 이 두 시스템은 진정한 융합 없이 병행적으로 발전해 왔습니다.
오늘날 스마트 계약은 대출, 차입, 스왑, 예치(stake) 은 물론 점점 더 복잡한 금융 로직을 구성할 수 있습니다. 그러나 바이낸스와 같은 고성능 마켓플레이스나 하이퍼리퀴드와 같은 고급 온체인 플랫폼에서 직접 거래를 실행할 수는 없습니다. 동시에, 가장 풍부한 유동성과 가장 강력한 거래 엔진은 여전히 고립된 플랫폼에 머물러 있어 온체인 프로그램이 근본적으로 접근할 수 없습니다.
이러한 분리는 흔히 사용자 경험, 지연 시간 또는 처리량 때문이라고 여겨지지만, 실제로는 더 근본적인 아키텍처적 한계를 반영합니다. 즉, 거래 기능은 DeFi 스택의 호출 가능한 구성 요소로 설계되지 않았다는 것입니다.
핵심적인 제약은 성능이 아니라 호출 가능성입니다.
대부분의 DeFi 거래 관련 논의는 가스 비용이나 분산된 유동성에 초점을 맞춥니다. 이러한 문제들도 중요하지만, 근본적인 원인은 아닙니다.
근본적인 한계는 간단합니다. 거래 엔진은 스마트 계약에서 호출할 수 없습니다. 중앙 집중식 거래소나 주문장 기반 탈중앙화 거래소(DEX)와 같은 고성능 실행 시스템은 DeFi의 프로그래밍 환경 외부에서 작동합니다. 이러한 시스템은 현물 및 무기한 시장, 고급 주문 유형, 풍부한 유동성을 제공하지만 온체인 로직의 일부로 호출될 수는 없습니다.
결과적으로 거래는 프로토콜이 직접 의존할 수 있는 기본 블록 가 아니라 사용자 또는 오프체인 봇에 의해 조정되는 외부 활동으로 남아 있습니다.
기존 탈중앙화 거래소(DEX) 아키텍처가 격차를 해소할 수 없는 이유는 무엇일까요?
현재의 DeFi 아키텍처는 문제의 절반만 해결하고 있으며, 진정한 자율적 실행을 막는 구조적 공백을 남기고 있습니다.
AMM: 전원 없이 프로그래밍 가능
자동 시장 조성자(AMM)는 프로그래밍이 가능하지만 실행 능력은 미흡합니다. 수동적인 유동성 곡선에 의존하기 때문에 레버리지나 복잡한 트리거를 기본적으로 표현할 수 없습니다. 코드를 시험해 볼 수 있는 환경을 제공하지만 전문적인 거래에 필요한 강력한 기능은 부족합니다.주문서 기반 DEX: 코드가 아닌 사람을 위해 설계됨
Hyperliquid와 같은 성능 중심 플랫폼은 풍부한 의미론적 기능을 제공하지만 , 프로토콜을 위한 인프라가 아닌 사용자를 위한 애플리케이션으로 설계되었습니다.- 서명 장벽: 이러한 플랫폼은 EOA(외부 소유 계정) 서명을 기반으로 구축되었습니다. 즉, 사람이 버튼을 클릭하거나 봇이 오프체인 API 키를 사용해야 합니다.
- "API"의 막다른 길: 이들은 오프체인 봇을 위한 정교한 백엔드 API를 제공하지만, 스마트 계약을 위한 온체인 진입점은 제공하지 않습니다 . 금고나 분산형 자율 조직(DAO) 이러한 플랫폼에서 요구하는 방식으로 거래에 "서명"할 수 없으므로, 사실상 탈중앙화 코드의 접근을 차단합니다.
고립된 섬 vs. 호출 가능한 원시 요소
이러한 플랫폼들은 사용자 중심적인 UI를 우선시하기 때문에, 마치 고립된 목적지처럼 작동합니다. 따라서 더 큰 DeFi 전략에 "소환"되거나 통합될 수 없습니다.
이로 인해 지속적인 상충 관계가 발생합니다. AMM은 전력 소모 없이 프로그래밍 기능을 제공하는 반면, 주문장 방식의 DEX는 스마트 계약을 부차적인 요소로 취급하면서 실행 기능만 제공합니다.
DeCeFi의 비전: 주권적인 "시스템 호출"로서의 거래
현재의 장벽이 EOA 서명과 격리된 애플리케이션을 중심으로 구축되어 있다면, 근본적인 아키텍처 변화가 필요합니다. 온체인 로직과 고성능 실행 간의 경계가 완전히 사라진다면 어떨까요?
우리는 이러한 새로운 패러다임 DeCeFi(분산형- 중앙화 금융) 라고 부릅니다.
“DeCeFi는 온체인 프로토콜과 스마트 계약이 중앙거래소(CEX) 수준의 실행력과 풍부한 유동성을 핵심 요소로 활용하는 패러다임 입니다. 이 세상에서 거래 엔진은 더 이상 방문하는 목적지가 아니라, 스마트 계약 호출이 가능한 인프라, 즉 복잡하고 조합 가능한 금융 전략을 구축하기 위해 코드가 호출하는 DeFi의 '트레이딩 레고'가 됩니다.”
시스템 아키텍처: 콜러블 트레이딩 작동 방식
저희의 설계 철학은 스마트 계약을 글로벌 시장의 핵심 요소 로 격상시키는 것입니다. 독자적인 오라클 기반 실행 모델을 활용하여 모든 블록체인의 스마트 계약이 중앙거래소(CEX) 수준의 실행과 풍부한 유동성을 직접 확보할 수 있도록 함으로써, 전문 트레이딩을 탈중앙화 금융(DeFi)의 '트레이딩 레고' 로 탈바꿈시킵니다. 이는 탈중앙화된 세상을 위한 완벽하게 구성 가능한 빌딩 블록 과 같습니다.
크게 보면, 우리는 거래를 두 개의 긴밀하게 연결된 계층으로 분리합니다. 하나는 확정적 실행 엔진이고, 다른 하나는 스마트 계약에서 이 실행을 안전하게 호출할 수 있도록 하는 크로스체인 액세스 계층입니다.
결정론적 거래 엔진을 실행 핵심으로 사용
이 시스템의 핵심은 결정론적 상태 기계처럼 작동하는 고성능 거래 엔진입니다. 주문 체결 및 취소, 포지션 개설 및 청산, 자금 입금, 마진 업데이트, 청산 등 모든 거래 활동은 단일의 표준 실행 파이프라인을 통해 처리됩니다.
결정론은 근본적인 속성입니다. 동일한 이전 상태와 동일한 순서의 요청 집합이 주어지면 엔진은 항상 동일한 결과를 생성합니다. 이는 실행을 감사하고, 재현하고, 독립적으로 검증할 수 있도록 합니다. 또한 합의 하에 여러 노드에서 엔진을 실행할 수 있게 하여 분산형 무결성 및 미래 지향적인 시스템의 기반을 마련합니다.
엔진 관점에서 모든 동작은 단순히 요청일 뿐입니다. 해당 요청이 저지연 API 클라이언트에서 발생했든 다른 체인의 스마트 계약에서 발생했든, 일단 실행 대기열에 들어가면 아무런 차이가 없습니다. 이러한 통합을 통해 모든 소비자는 동일한 유동성, 동일한 실행 로직, 그리고 동일한 상태 전환을 공유하게 됩니다.
오라클 스타일 게이트웨이를 통해 실행 호출 가능화
스마트 계약은 오프체인 고성능 거래 엔진과 직접 상호 작용할 수 없습니다. 실행을 호출할 수 있도록 데이터보다는 실행에 초점을 맞춘 오라클 방식의 게이트웨이를 도입했습니다.
위 다이어그램은 온체인 요청부터 검증된 실행 및 온체인 결제에 이르는 핵심 실행 흐름을 보여줍니다. 계약, 릴레이어, 거래 엔진이 실제로 어떻게 상호 작용하는지 등 이 프로세스의 전체적인 과정을 보다 직관적으로 살펴보려면 다음 링크에서 실행 워크플로의 UI/UX 데모를 확인하세요. https://www.128.trade/how-it-works
전체적인 워크플로는 다음과 같습니다.
온체인 의도.
스마트 계약은 게이트웨이 함수(예: 주문 체결, 포지션 개설, 전략 구독)를 호출합니다.
이는 온체인에서 거래를 실행하지 않습니다. 대신, 실행 의도, 매개변수, 출발지 체인 컨텍스트 및 고유한 요청 ID를 인코딩하는 정규 요청 이벤트를 발생시킵니다.전달 요청.
분산형 릴레이어 네트워크는 게이트웨이 이벤트를 모니터링하고, 이벤트의 출처를 검증하며, 인증된 요청을 거래 엔진으로 전달합니다.
엔진 관점에서 이러한 요청은 API 기반 주문과 구별할 수 없으며 동일한 결정론적 실행 대기열에 들어갑니다.결정론적 실행.
거래 엔진은 주문을 매칭하고, 마진을 업데이트하고, 자금을 적용하거나, 청산을 실행하는 등의 요청을 처리하고 확정적인 실행 결과를 생성합니다.검증된 콜백.
실행 결과는 암호학적 증명 묶음(예: 스레스홀드(Threshold) 서명 또는 실행 증명)과 함께 콜백을 통해 비동식으로 원래 체인에 반환됩니다.
게이트웨이는 증명을 검증하고, 멱등성 및 재실행 공격 방지 기능을 적용한 후에야 온체인에 결과를 적용합니다.온체인 구현.
검증된 결과는 온체인 상태(예: NFT 보유량, 볼트 공유 지분, 잔액 업데이트 또는 계약 콜백)로 구체화됩니다.
이 아키텍처를 통해 지원되는 모든 체인의 스마트 계약은 자산 연결, 네트워크 전환 또는 단일 운영자에 대한 신뢰 없이도 현물, 무기한, 지정가 및 트리거 주문과 같은 거래소 수준의 거래를 실행할 수 있습니다. 실행은 호출 가능한 시스템 기본 요소가 되며, 정확성은 온체인에서 보장됩니다.
개발자 관점에서 보면, 거래는 외부 의존성에서 호출 가능한 시스템 호출로 전환됩니다. 스마트 계약은 실행 의도를 표현하고, 거래 엔진은 확정적인 실행을 수행하며, 검증된 결과는 콜백을 통해 온체인에 다시 구현됩니다. 프로토콜은 더 이상 거래소와 통합되지 않고, 실행 기능을 자체 로직에 직접 통합합니다.
아래 예시는 실제 작동 방식을 보여줍니다. 스마트 계약은 placePerpOrder 호출하여 무기한 주문을 체결할 수 있으며, 이 함수는 오라클 계층을 통해 거래 엔진에 실행 요청을 보냅니다. 주문이 실행되면 결과가 비동기적으로 반환되며, 개발자는 해당 콜백 함수를 구현하여 계약 로직 내에서 이를 처리할 수 있습니다.
function placePerpOrder ( PerpOrderParams calldata params )external payable override returns (bytes32 requestId) { // submit a perpetual order request to the trading engine via the oracle requestId = oracle. submitRequest { value : value}(params); return requestId;} function onPlacePerpOrderResult ( ... ) external onlyOracle { // handle the execution result of the perpetual order // custom logic defined by the contract developer }하나의 엔진, 두 개의 세계
동일한 거래 엔진이 근본적으로 다른 두 소비자에게 동시에 서비스를 제공합니다. 한편으로는 거래자, 시장 조성자 및 자동화 시스템이 성능에 최적화된 저지연 API를 통해 상호 작용합니다. 다른 한편으로는 스마트 계약 및 프로토콜이 신뢰 최소화 및 증명 기반 게이트웨이를 통해 엔진에 접근합니다.
두 접근 경로는 모두 동일한 실행 계층으로 수렴합니다. 유동성, 실행 의미 체계 및 상태 전환을 공유합니다. 이것이 바로 거래가 고립된 환경에서 공유 인프라로 전환되는 이유입니다.
이것이 DeFi에 가져올 가능성은 무엇일까요?
스마트 계약을 통해 고성능 거래를 호출할 수 있게 됨으로써 DeFi는 이전에는 결코 갖지 못했던 기능들을 활용할 수 있게 되었습니다.
스마트 계약은 거래소 수준의 거래에 직접 접근할 수 있습니다.
바이낸스 수준의 실행 방식을 통해 현물 및 무기한 거래를 체결할 수 있으며, 여기에는 지정가 주문, 트리거 주문, 레버리지 및 고급 주문 로직이 포함됩니다. 이제 거래는 더 이상 사용자나 봇이 조정하는 오프체인 활동이 아니라 프로토콜이 직접 호출할 수 있는 프로그래밍 가능한 기능이 됩니다.거래 상태는 온체인에서 구성 가능하게 됩니다.
현물 잔액, 무기한 포지션, 하위 계좌, 전략 포트폴리오와 같은 거래소 고유의 객체들을 온체인 자산으로 표현할 수 있습니다. 포지션과 하위 계좌는 더 이상 거래소 내에 잠겨 있지 않으며, 담보 제공, 대출, 스테이킹 또는 구조화 상품에 포함될 수 있습니다.프로토콜은 능동적인 실행과 새로운 설계 공간을 확보하게 됩니다.
금고와 펀드는 더 이상 근사치에 의존하지 않고 직접 거래할 수 있습니다. 대출 프로토콜은 초과 담보화 에만 의존하는 대신 조건부 실행을 통해 위험을 헤지하고 관리할 수 있습니다. 동시에, 완전한 온체인 펀드, 적극적인 헤징 기능을 갖춘 AMM, 검증 가능한 보증을 통해 자본 관리하는 자율 거래 에이전트 등 완전히 새로운 유형의 프로토콜이 가능해집니다.
그 결과는 또 다른 거래소가 아니라 아키텍처의 전환입니다. 거래는 목적지가 아닌 공유 인프라가 되며, 프로토콜이 데이터 및 유동성과 마찬가지로 구성하는 핵심 실행 계층이 됩니다.
경쟁 구도: 경기장 vs. 인프라
기존 프로젝트 대부분은 거래 환경을 개선하는 데 중점을 두고 있습니다.
128.trade는 거래를 인프라로 재정의합니다.
기존 모델과의 비교
| 프로젝트 | 범주 | 이 제품이 제공하는 것은 무엇일까요? | 구조적 제한 | 128. 무역 차이 |
|---|---|---|---|---|
| 디와이디엑스(DYDX) / 아스터 / 라이터 | 범죄자 탈중앙화 거래소(DEX) | 온체인 무기한 거래 | 단일 체인 애플리케이션은 임의의 스마트 계약에서 호출할 수 없습니다. | 멀티 체인 호출 가능 실행 엔진 |
| 하이퍼리퀴드 | 맞춤형 L1 거래소 | 고성능 주문장 + HyperEVM | 상호 운용성은 자체 생태계에 국한됩니다. | 오라클 방식 게이트웨이를 통한 모든 체인 통합 |
| 유니스왑(Uniswap) / 1인치(1INCH) | 자동화된 마켓 마이커(AMM) 탈중앙화 거래소(DEX) | 완전 프로그래밍 가능한 스왑 | 제한된 실행 의미론 (기본적인 목표 주문, 레버리지, 트리거 주문 없음) | 현물 및 무기한 주문 전체 체결, 고급 주문 유형 지원 |
| 체인링크(Chainlink) | 데이터 오라클 | 검증 가능한 오프체인 데이터 | 정보를 제공할 뿐, 실행을 제공하지는 않습니다. | 실행 오라클 - 데이터뿐 아니라 검증 가능한 액션 |
128.trade가 스택에서 차지하는 위치
| 층 | 체인링크(Chainlink) | 하이퍼리퀴드 | 128.거래 |
|---|---|---|---|
| 그것이 제공하는 것 | 데이터 | 거래소 | 거래 인프라 |
| 누가 통합하는가 | 프로토콜 | 거래자 | 프로토콜 및 거래자 |
| 배포 모델 | 프로토콜 네이티브 | 앱 네이티브 | 프로토콜 네이티브, 크로스체인 |
| 구성 가능성 | 높은 | 낮은 | 높은 |
| 성장 한계 | DeFi 전반 | 행사장행 | DeFi 전반 |
| 수익화 | 통화당 오라클 수수료 | 거래 수수료 | 실행 계층 거래 수수료 |
새로운 카테고리
128.trade는 다음을 결합합니다:
- 체인링크의 프로토콜 수준 분산
- Hyperliquid의 실행 깊이
- CEX급 유동성 및 주문 의미론
하지만 목적지가 되는 대신, 호출 가능한 실행 기본 요소가 됩니다.
우리는 또 다른 거래소를 건설하는 것이 아닙니다.
새로운 카테고리를 소개합니다:
거래 인프라 계층.
앞으로의 전망
128.trade는 현재 활발히 개발 중이며, 테스트넷이 곧 출시될 예정입니다. 시스템이 성숙해짐에 따라 스마트 계약 인터페이스와 핵심 구성 요소가 오픈 소스 계약 코드와 함께 개발자들에게 점진적으로 공개될 것입니다.
아키텍처, 신뢰 모델 및 실행 보장에 대한 더 자세한 기술적 내용은 전체 백서 참조하십시오. 백서
우리는 거래가 고립된 공간이 아니라 프로그래밍 가능한 기본 요소가 되어야 한다고 믿으며, 이것이 바로 그것을 현실로 만들기 위한 첫걸음입니다.




