[XRPL] XRPL에 대해 알아보자
Ledger
구조
XRP Ledger는 data block이 연결되어 있는 blockchain이다.
block 하나를 ledger version 또는 ledger라고 표현한다.
ledger는 3가지 부분으로 나뉜다.
1. header는 ledger를 요약해 주는 정보를 가지고 있다. 해당 정보는 아래와 같다.
- ledger index는 chain 상에서 ledger의 위치를 나타낸다.
- ledger hash는 ledger의 content를 유일하게 식별해 주는 값으로 content가 바뀌면 hash 값도 바뀐다.
- parent ledger hash는 바로 직전 ledger의 hash이다.
- close time은 ledger의 content가 확정되는 시간이다.
- state data hash는 state data의 hash 값이다.
- transaction set hash는 transaction set의 hash 값이다.
2. transaction set은 ledger를 변화시키는 transaction의 집합이다.
transaction은 instruction과 metadata로 나뉜다.
3. state data는 ledger의 snapshot이다.
state data는 ledger entry라고 불리는 객체들이 tree 형태로 이뤄져 있다.
각 ledger entry는 고유한 256 bit를 가지며 tree에서 검색할 수 있다.
상태
ledger는 open, closed, validated 상태를 가질 수 있다.
open 상태를 가진 ledger는 시간순으로 transaction을 수신한다.
하지만 네트워크 상의 각 서버들은 중앙 시간 관리자가 없기 때문에 서버마다 다른 순서로 transaction을 수신할 수 있다.
일정 시간이 지나면 각 서버들은 표준 순서에 따라 수신한 transaction들을 정렬시킨다.
ledger는 closed 상태가 된다.
validator 서버는 closed 상태의 ledger들을 비교하고 하나로 합의하게 된다.
ledger는 validated 상태가 된다.
ledger의 header에는 close time 필드가 있는데 ledger가 closed 상태로 변하는 시간을 나타낸다.
새로운 ledger의 close time은 바로 직전의 close time보다 빠르면 안 된다.
빨라지는 상황이 오면 새로운 ledger의 close time은 바로 직전의 close time에 1초를 더한 시간이 된다.
Consensus
구조
XRP Ledger 서버에는 tracking 서버와 validator 서버가 있다.
tracking 서버와 validator 서버는 모두 client로부터 트랜잭션을 수신하고 네트워크로 전파하는데
validating 서버는 추가적으로 ledger를 검증하고 합의하는 역할을 한다.
validator 서버는 다음 ledger에 포함될 트랜잭션 집합을 정하고 다른 validator 서버로 제안한다.
UNL은 신뢰할 수 있는 validator 서버의 집합으로 UNL의 대다수가 동일한 트랜잭션 집합을 가질 때까지
트랜잭션 집합을 수정하고 제안하는 과정을 반복한다.
다음 ledger에 포함될 트랜잭션이 집합이 정해지면
validator 서버는 이전 ledger에 트랜잭션을 적용해서 새로운 ldeger를 계산하고
새로운 ledger의 hash를 다른 validator 서버로 제안한다.
UNL의 대다수가 동일한 hash를 가지게 되면 해당 ledger를 validated ledger로 확정한다.
validated ledger와 다른 ledger를 가진다면 자신이 가진 ledger를 버리고 validated ledger를 사용한다.
Payment
Escrow
escrow는 자금과 관련된 transaction을 용이하게 해주는 계약으로
자금을 보류했다가 계약에 명시한 조건을 만족시키면 자금을 이용할 수 있다.
escrow의 종류는 다음과 같다.
1. time based escrow는 특정 시간이 지나면 자금을 이용할 수 있다.
2. conditional escrow는 특정 조건을 만족시키면 자금을 이용할 수 있다.
3. combinational escrow는 time based escrow와 conditional escrow를 합친 것으로
특정 시간이 지나고 특정 조건을 만족시키면 자금을 이용할 수 있다.
escrow의 흐름은 아래와 같다.
1. sender는 얼마 큼에 자금에 잠금을 걸지, 어떤 조건을 만족시켜야 자금을 풀지, 자금의 수신자는 누군지를 정해서
EscrowCreate라는 transaction을 보낸다.
2. transaction이 처리되면서 XRP Ledger는 자금의 정보를 가지고 있고 Escrow 객체를 생성한다.
3. recipient는 EscrowFinish라는 transaction을 보내고 조건을 만족시키면 Escrow 객체를 소멸시키고 자금을 가져온다.
하지만 escrow가 expiration time을 가지고 있을 경우 시간 안에 transaction을 성공시키지 못하면
Escrow 객체는 처리되지 못하고 XRP Ledger에 남게 된다.
EscrowCancel transaction을 통해 해당 Escrow 객체를 소멸시키고 자금을 sender로 다시 보낼 수 있다.
escrow는 escrow를 생성시키는 transaction과 끝내는 transaction이 필요하기 때문에
평소보다 수수료가 많이 발생하므로 소액 이동에는 적합하지 않다.
Checks
현실 세계의 수표와 같은 개념으로 결제를 연기할 수 있다.
check가 생성이 된 시점에 자금의 이동은 없지만 check을 자금화하려는 순간 자금의 이동이 발생한다.
하지만 발행인의 계좌에 충분한 자금이 없을 경우 transaction은 실패할 수 있다.
checks의 흐름은 아래와 같다.
1. sender는 check 수신자가 누군지, 유효기간은 언제까지인지, 계좌에서 인출할 수 있는 최대 자금은 얼마인지 정해서
CheckCreate라는 transaction을 보낸다.
2. transaction이 처리되면서 XRP Ledger는 Check 객체를 생성한다.
3. recipent는 CheckCash라는 transaction을 통해서 자금을 전달받고 Check 객체를 소멸시킨다.
하지만 sender가 충분한 자금을 가지고 있지 못하거나 유효시간이 지나면 transaction은 실패한다.