XRP Ledger의 DEX
1. XRP Ledger의 DEX
XRP Ledger의 DEX는 스마트 컨트랙트로 만들어진 것이 아닌 프로토콜에 내장 되어 있는 오더북 방식의 DEX입니다. 이러한 이유로 XRP Ledger의 DEX는 다른 블록체인에서의 DEX와는 다른 특징을 가지고 있습니다. 이번 장에서는 XRP Ledger의 DEX가 어떻게 작동하는지, 그리고 어떤 장점을 가지는지와 그 기능들에 대해 자세히 알아보겠습니다.
2. XRP Ledger DEX의 차별점
보안
대부분의 DEX는 스마트 계약에 의존하는데, 스마트 계약은 코드상의 결함이나 오류로 인해 보안 취약점이 발생할 수 있습니다. 반면, XRP Ledger DEX는 프로토콜 수준에서의 동작을 통해 스마트 계약의 필요성을 배제합니다. 이러한 접근 방식은 잠재적인 보안 위험을 크게 줄여줍니다.
속도
XRP Ledger DEX에서의 거래는 블록체인의 핵심 레이어에서 바로 처리됩니다. 이는 거래를 위한 별도의 계층이나 복잡한 스마트 계약의 실행 없이 바로 블록에 기록될 수 있음을 의미합니다. 특히, XRP 원장의 합의 알고리즘은 빠른 거래 확인을 가능하게 합니다. 이러한 구조 덕분에 XRP Ledger DEX는 거래 확정 시간을 크게 줄일 수 있으며, 결과적으로 3-5초 안에 거래를 확정하는 높은 처리 속도를 제공합니다. 이런 방식은 다른 분산 거래소에서 사용하는 여러 스마트 계약의 복잡한 호출과 비교할 때, 명확한 시간적 우위를 갖게 됩니다. 이로 인해 사용자는 거래의 안정성과 신속성을 동시에 경험할 수 있습니다.
유동성
XRP Ledger DEX는 XRP 원장의 프로토콜 수준에서 직접 통합되어 있습니다. 이러한 깊은 통합으로 인해 전체 XRP 원장 블록체인의 유동성이 공유되게 됩니다. 통합된 원장의 구조는 거래 과정을 간소화시켜, 전체 네트워크의 거래량을 크게 증가시키는 요인이 됩니다.
더불어, XRP Ledger DEX는 auto-bridging라는 독특한 기능을 통해 특정 토큰 간의 직접적인 거래 수요가 부족하더라도 거래가 원활하게 이루어질 수 있게 지원합니다. 이 기능은 XRP를 중개 토큰으로 활용하여 두 다른 토큰 간의 거래를 연결시켜줍니다.
다양성
XRP Ledger DEX는 여러 가지 기능을 제공합니다. 사용자는 지갑 간에 직접 거래할 수 있으며, IOU(나중에 지불하겠다는 약속의 의미를 갖는 디지털 증서)를 추가하여 거래의 다양성을 높일 수 있습니다. 또한, 여러 암호화폐와 전통적인 피아트(Fiat) 화폐도 지원되어 더 광범위한 거래 옵션을 제공합니다.
3. XRP Ledger DEX의 구조
1) 통화 쌍의 구성
XRP Ledger DEX 무제한의 통화 쌍을 지원합니다. 이 특성은 전 세계의 다양한 토큰과 자산 간의 거래를 가능하게 하며, 궁극적으로 XRP Ledger DEX의 확장성과 유연성을 향상시킵니다.
실시간 통화 쌍 처리: XRP Ledger DEX의 주요 특징 중 하나는 사용자의 거래 요청에 따라 실시간으로 통화 쌍을 처리하는 능력입니다. 이는 Ledger가 고도로 반응성 있고 효율적으로 작동함을 의미하며, 사용자에게 빠른 거래 확인 시간을 보장합니다.
통화 쌍의 다양성: 거래소는 단순히 XRP와 다른 토큰 간의 거래만을 지원하는 것이 아닙니다. 두 개의 서로 다른 토큰으로 구성된 통화 쌍도 처리할 수 있습니다. 이것은 사용자가 자신의 포트폴리오에 다양한 자산을 포함하고 다양한 통화 쌍 간의 거래 전략을 채택할 수 있음을 의미합니다.
고유한 토큰 식별 체계: 각 토큰은 발행자와 통화 코드의 조합으로 고유하게 식별됩니다. 이 고유한 식별 체계는 XRP Ledger DEX에서의 거래의 투명성과 신뢰성을 보장합니다. 사용자는 토큰의 정확한 출처와 유형을 항상 알 수 있으므로 거래의 안정성과 정확성이 보장됩니다.
유연한 거래 옵션: 동일한 통화 코드를 가진 다른 발행자의 토큰 또는 동일한 발행자의 다른 통화 코드를 가진 토큰 간의 거래도 가능합니다. 이렇게 해서 사용자는 필요에 따라 다양한 통화 조합의 거래를 선택할 수 있습니다.
총론적으로, XRP Ledger의 분산형 거래소는 통화 쌍의 구성에 있어서 혁신적이며, 사용자 중심의 거래 경험을 제공하기 위해 설계되었습니다. 이러한 기능성과 유연성은 XRP Ledger DEX를 디지털 자산 거래의 선두 주자로 만듭니다.
2) 'Offer' 거래 메커니즘
2-1) Offer: XRP Ledger DEX의 거래 표현
XRP Ledger DEX에서의 거래는 'Offer'라는 주문 형태로 표현됩니다. 이 Offer는 사용자가 의도하는 거래 의도를 Ledger에 제시하는 방법으로, 특정 통화를 다른 통화로 교환하려는 의도를 명확하게 표현합니다.
지정가 주문: Offer는 주로 지정가 주문(limit order)의 형태로 나타납니다. 이는 사용자가 특정한 가격에 특정 통화를 구매 또는 판매하길 원할 때 사용하는 주문 유형입니다. 예를 들어, 사용자가 1 XRP를 $1.20에 팔기를 원할 경우, 이것을 Offer로 제시할 수 있습니다.
동적 매칭: Offer가 Ledger에 제출되면, 해당 Offer와 일치하는 다른 Offer가 있는지 즉시 확인됩니다. 만약 일치하는 Offer가 있을 경우, 최적의 환율(즉, 사용자에게 가장 유리한 환율)부터 거래가 시작됩니다. 이는 효율적인 거래 실행을 보장하며, 사용자에게 최상의 거래 경험을 제공합니다.
2-2) Offer의 실행 과정
Offer의 실행은 그 자체로 복잡한 과정을 거칩니다. 사용자가 제시한 조건에 따라 Offer는 다양한 방식으로 처리될 수 있습니다.
완전한 채움 vs 부분 채움: Offer는 두 가지 방식으로 채워질 수 있습니다. 첫째, Offer의 조건이 완전히 만족되어 전체 금액이 거래될 수 있습니다. 둘째, 조건이 부분적으로만 만족되어 Offer의 일부만 거래될 수 있습니다.
원장의 지속성: Offer가 부분적으로만 채워진 경우, 남은 부분은 Ledger에 계속 보관됩니다. 이 후속 Offer는 나중에 다른 Offer나 교차 통화 결제와 일치하여 소비될 수 있습니다.
유동적인 환율: Offer는 초기에 설정된 환율에 따라 거래될 수 있지만, 시장의 상황에 따라 더 나은 환율로 거래될 수도 있습니다. 이는 시장의 유동성과 거래의 수요 및 공급에 따라 달라집니다.
결론적으로, 'Offer'는 XRP Ledger의 거래 메커니즘에서 핵심 요소입니다. 사용자는 이 기능을 통해 자신의 거래 의도를 명확하게 표현할 수 있으며, Ledger는 이러한 의도를 효과적으로 처리하여 최적의 거래 결과를 제공합니다.
2-3) Offer의 취소
Offer가 XRP Ledger에 등록된 후에도 변경될 수 있습니다. 사용자에 의해 수동으로, 또는 특정 조건에 따라 자동으로 취소될 수 있습니다.
수동 취소: 사용자는 Offer를 수동으로 철회할 권한을 갖습니다. 이는 시장 조건이 예기치 않게 변경될 때 특히 유용합니다.
자동 트리거: Offer는 특정 조건이 충족될 때 자동으로 취소되도록 설정될 수 있습니다. 이러한 조건은 시간 제약, 가격 변동 등의 시장 동향에 기반할 수 있습니다.
잔여 제거: 부분 체결 후, 사용자가 Offer의 나머지 부분이 전략과 더 이상 일치하지 않다고 판단하면 제거할 수 있습니다.
비상 제거 메커니즘: Offer가 무기한으로 보류되지 않도록 하기 위한 내장 메커니즘이 설정될 수 있습니다.
XRP Ledger DEX는 취소 도구를 제공함으로써 사용자가 한 번의 결정에 얽매이지 않도록 도와주며, 항상 변하는 암호화폐 시장에서 유연성과 적응성을 보장합니다.
3) Auto-Bridging: 토큰 거래의 효율성과 최적화
Auto-Bridging는 XRP Ledger에서 제공하는 중요한 기능 중 하나로, 여러 토큰 간의 거래에서 최적의 환율과 유동성을 제공하도록 설계되었습니다. 토큰 간의 직접적인 거래가 항상 최적의 선택이 아닌 상황에서 이 기능은 중요한 역할을 합니다.
3-1) 기본 원칙
유동성 및 환율 최적화: Auto-Bridging는 토큰 간의 거래에서 사용할 수 있는 최상의 환율을 찾기 위해 XRP를 중개자로 사용합니다. 직접 거래가 가능하지 않거나 비효율적인 경우, XRP를 거친 거래를 통해 더 나은 거래 조건을 제공합니다.
자동 중개: 직접 거래가 경제적이지 않을 때, Auto-Bridging는 두 토큰 간의 거래를 자동으로 XRP를 통해 중개합니다. 이렇게 함으로써 사용자는 최적의 거래 경험을 얻을 수 있습니다.
3-2) 실제 사례 설명
토큰 A와 토큰 B 간에 직접적인 거래가 제한되거나 환율이 불리한 상황이 발생할 수 있습니다. 이러한 상황에서 Auto-Bridging는 다음과 같은 절차로 동작합니다:
사용자는 토큰 A를 토큰 B로 교환하길 원합니다.
XRP Ledger은 토큰 A와 토큰 B 사이의 직접적인 거래 환율을 확인합니다.
동시에 XRP Ledger은 토큰 A에서 XRP로, 그리고 XRP에서 토큰 B로의 거래 환율을 확인합니다.
두 경로 중 더 유리한 환율을 제공하는 경로를 선택합니다. 만약 XRP를 통한 경로가 더 유리하다면, 토큰 A를 XRP로 먼저 교환하고, 그 다음에 XRP를 토큰 B로 교환합니다.
이 전체 과정은 사용자에게 투명하게, 즉시, 자동으로 이루어집니다.
3-3) 결론
Auto-Bridging는 XRP Ledger의 혁신적인 기능 중 하나로, 여러 토큰 간의 거래를 최적화하여 사용자에게 더 나은 환율과 높은 유동성을 제공합니다. 이 기능을 통해 XRP Ledger은 다양한 토큰의 교환을 훨씬 더 효율적으로, 간편하게 처리할 수 있게 됩니다.
4) Tick Size
Tick Size는 거래소의 주문에서 허용되는 가장 작은 가격 변동을 나타냅니다. 이것은 특히 주문서의 가격 분산을 제어하고, 특히 고빈도 거래와 같은 특정 전략을 활용하는 트레이더에게 유리한 조건을 제한하는 데 사용됩니다.
Tick Size의 기능과 중요성
정밀도 제어: Tick Size는 주문서에서 가격의 정밀도를 제한합니다. 예를 들어, Tick Size가 0.01이면, 주문서의 모든 가격은 0.01의 배수로 표시되어야 합니다.
시장 조작 방지: 너무 작은 Tick Size를 허용하면 트레이더가 미세한 가격으로 주문서를 '전방에 세우는' 전략을 사용하여 시장을 조작할 수 있습니다. 적절한 Tick Size 설정은 이러한 활동을 제한하여 시장의 효율성과 진정성을 유지하도록 도와줍니다.
주문서의 간결성: Tick Size가 적절하게 설정되면 주문서는 더 간결하고 이해하기 쉬워집니다. 이로 인해 트레이더들은 빠르게 의사 결정을 내릴 수 있게 됩니다.
5) XRP Ledger DEX에서의 Tick Size
XRP Ledger DEX에서는, 특정 통화 쌍에 대한 거래소의 Tick Size를 설정할 수 있는 기능을 제공합니다. 이는 발행자가 그들의 토큰에 대한 거래의 최소 가격 변동을 제어할 수 있게 해줍니다.
토큰 발행자는 이를 통해 그들의 토큰 가치의 안정성을 증진시키거나, 시장의 유동성을 제어하는 데 도움을 줄 수 있습니다. 하지만, 너무 큰 Tick Size는 거래를 어렵게 만들 수 있으므로, 발행자는 이 값을 조심스럽게 설정해야 합니다.
결론적으로, Tick Size는 거래소의 가격 결정 메커니즘과 시장의 효율성에 중요한 역할을 합니다. XRP Ledger DEX에서는 이를 통해 트레이더와 발행자 모두에게 유리한 환경을 제공하려고 노력합니다.
4. Offer
XRP Ledger에서의 DEX 거래 주문은 Offer라고 부릅니다. Offer를 사용하면 XRP와 토큰 간의 거래 또는 다른 토큰 간의 거래가 가능하며, 동일한 통화 코드를 가지지만 발행자가 다른 토큰 간의 거래도 포함됩니다. 이러한 토큰은 때때로 rippling을 통해 교환될 수 있습니다.
4-1) 주문 생성 및 처리
OfferCreate transaction을 전송하여 Offer를 생성할 수 있습니다.즉시 완전히 채워지지 않는 Offer는 원장 데이터 내의
Offer 객체가 됩니다. 후속의 Offer나 Payments는 원장에서 이 Offer 객체를 사용할 수 있습니다.Cross-currency payments는 유동성을 제공하기 위해 Offer를 사용하지만, 원장 내에서 Offer 객체를 생성하지는 않습니다.
4-2) Offer의 생명주기
OfferCreate transaction은 두 토큰 또는 토큰과 XRP 간의 거래를 진행하기 위한 지시입니다. 모든 거래에는 구매 금액(TakerPays)과 판매 금액(TakerGets)이 포함됩니다. 거래가 처리될 때, 가능한 한 많은 일치하는 Offer를 자동으로 사용합니다. 새로운 Offer가 완전히 채워지지 않으면 나머지는 원장의 Offer 객체가 됩니다.
원장에 있는 동안 다른 Offer나 cross-currency payments에 의해 완전히 사용될 때까지 Offer 객체는 원장에 대기합니다. Offer를 게시한 계정은 Offer의 소유자로 불립니다. 사용자는 언제든지 전용 OfferCancel transaction을 사용하거나 OfferCreate transaction의 옵션으로 자신의 Offer를 취소할 수 있습니다.
원장에 Offer가 있으면, 사용자의 XRP 중 일부를 reserve(예비금)으로 할당합니다. Offer가 어떤 이유로든 제거되면 그 XRP는 다시 해제됩니다.
4-3) Offer의 다양한 유형
Buy vs. Sell: 기본적으로 Offer는 "buy" Offer이며, "buy" (
TakerPays) 금액 전체를 획득했을 때 완전히 채워진 것으로 간주됩니다. 반대로 "Sell" Offer는 "sell" (TakerGets) 금액 전체를 소비했을 때만 완전히 채워진 것으로 간주됩니다.Immediate or Cancel Offer는 원장에 배치되지 않으며, 거래가 처리될 때 존재하는 일치하는 Offer에 따라 금액만 거래됩니다.
Fill or Kill Offer는 원장에 배치되지 않으며, 초기에 완전히 채워지지 않으면 취소됩니다.
Passive Offer는 동일한 환율을 가진 일치하는 Offer를 사용하지 않고 직접 원장에 배치됩니다.
4-4) 거래의 자금 요건
Offer를 게시하려고 할 때 거래가 판매될 자산의 일부를 보유하고 있지 않으면 "unfunded"로 거절됩니다. 특히:
토큰을 판매하려면 해당 토큰의 양수량을 보유하거나 해당 토큰의 발행자가 되어야 합니다.
XRP를 판매하려면, Offer 객체를 원장에 배치하고 구입할 토큰을 보유하기 위한 신뢰선의 예비금을 포함하여 모든 reserve requirements를 충족해야 합니다.
4-5) Offer와 신뢰
trust lines의 한도 값은 Offer에 영향을 주지 않습니다. 하지만 토큰을 보유하려면 발행자에게 신뢰선이 필요합니다. Offer가 사용될 때 필요한 신뢰선을 자동으로 생성하며, 한도를 0으로 설정합니다.
4-6)Offer의 우선순위
현재의 Offers는 TakerGets와 TakerPays 사이의 비율로 측정되는 환율에 따라 그룹화됩니다. 높은 환율을 가진 Offers가 우선적으로 처리됩니다.
4-7) Offer의 만료
Offer를 게시할 때 선택적으로 만료 시간을 추가할 수 있습니다. 기본적으로 Offer는 만료되지 않습니다. 이미 만료된 새로운 Offer를 만들 수는 없습니다.
4-8) Offer의 JSON 표현
XRP Ledger 상의 Offer 객체는 다음과 같이 표현됩니다.
{
"Account": "rBqb89MRQJnMPq8wTwEbtz4kvxrEDfcYvt",
"BookDirectory": "ACC27DE91DBA86FC509069EAF4BC511D73128B780F2E54BF5E07A369E2446000",
"BookNode": "0000000000000000",
"Flags": 131072,
"LedgerEntryType": "Offer",
"OwnerNode": "0000000000000000",
"PreviousTxnID": "F0AB71E777B2DA54B86231E19B82554EF1F8211F92ECA473121C655BFC5329BF",
"PreviousTxnLgrSeq": 14524914,
"Sequence": 866,
"TakerGets": {
"currency": "XAG",
"issuer": "r9Dr5xwkeLegBeXq6ujinjSBLQzQ1zQGjH",
"value": "37"
},
"TakerPays": "79550000000",
"index": "96F76F27D8A327FC48753167EC04A46AA0E382E6F57F32FD12274144D00F1797"
}자세한 내용은 Offer Objects를 참고하세요.
4-9) Offer 관련 트랜잭션
4-10) Offer 관련 리퀘스트
Last updated